state of ohio – rfp: peoplesoft managed services and...

State of Ohio – RFP: PeopleSoft Managed Services and Project Services 2008

Supplement Two: Scope of Work and

Project Requirements

Page [1]


Table of ContentsSupplement Two: Scope of Work and Project Requirements....................................................................1

Table of Contents........................................................................................................................................2

1 Introduction.........................................................................................................................................6

2 Current Situation Overview.................................................................................................................8

2.1 Services Areas..............................................................................................................................8

3 High Level Scope of Services..............................................................................................................12

3.1 RFP Overview.............................................................................................................................12

3.2 Managed Services High Level Scope..........................................................................................12

3.3 Ongoing Project Services Scope.................................................................................................16

3.4 Shared Services Implementation Scope.....................................................................................17

4 Required Differentiators....................................................................................................................19

4.1 Offeror Required Differentiators and Qualifications..................................................................19

4.2 Other Key Differentiators...........................................................................................................20

4.3 Foundational Concepts..............................................................................................................20

4.4 Information Technology Infrastructure Library (ITIL).................................................................20

5 Required Operating Environment......................................................................................................24

5.1 General......................................................................................................................................24

5.2 Operational and Strategic Objectives........................................................................................24

5.3 Data Center Environment and Personnel Requirements...........................................................27

6 Current Technical Environment Overview.........................................................................................29

6.1 General......................................................................................................................................29

6.2 Processing Profile Key Statistics.................................................................................................31

6.3 Current Hardware Configurations..............................................................................................32

6.4 Current Network Configuration.................................................................................................36

6.5 PeopleSoft Modules, Versions and Associated Third Party Elements........................................38

6.6 PeopleSoft Operations Software................................................................................................40

6.7 Supporting Application Software...............................................................................................40

6.8 Supporting Operations Software...............................................................................................40

Page [2]


6.9 Development-Specific Software Deployments...........................................................................41

6.10 Administrator Workstation Software Deployments...................................................................42

6.11 High Availability: Current Capabilities........................................................................................42

6.12 Run Book, Operations and Production Scheduling....................................................................44

6.13 PeopleSoft Implemented Modifications....................................................................................46

6.14 Current Reports.........................................................................................................................51

6.15 Data Transfer Programs.............................................................................................................51

6.16 Key Interfaces by System...........................................................................................................51

7 Overall Program Governance Requirements.....................................................................................56

7.1 Contractor Account Representative...........................................................................................56

7.2 State Account Representative...................................................................................................56

7.3 Establishment of Service Management Steering and Oversight Committee.............................56

7.4 Establishment of a Managed Services Oversight Council...........................................................57

7.5 Key Personnel............................................................................................................................57

7.6 Regular Meetings and Conference Calls....................................................................................58

7.7 System Changes.........................................................................................................................58

7.8 Extraordinary Events..................................................................................................................59

7.9 Dispute Resolution.....................................................................................................................59

7.10 Billing, Invoicing and Reporting.................................................................................................61

7.11 Benchmarking............................................................................................................................63

7.12 Contractor Best Practices...........................................................................................................66

7.13 SAS-70 Reporting.......................................................................................................................66

8 Managed Services SOW.....................................................................................................................68

8.1 General......................................................................................................................................68

8.2 Organization of Service Delivery Areas......................................................................................69

8.3 Transition Services.....................................................................................................................69

8.4 Technology Update and Refresh Services..................................................................................79

8.5 Steady-State Operations and Maintenance Services.................................................................80

8.6 Infrastructure Management Services........................................................................................85

8.7 Ongoing Application Responsibilities.........................................................................................89

8.8 Program Management Services.................................................................................................95

Page [3]


8.9 Disaster Recovery & Business Continuity.................................................................................100

8.10 Maintaining Solution and Operations Documentation............................................................102

8.11 Mandatory Full Lifecycle SDLC Deliverables and Process.........................................................102

8.12 Termination and Termination Assistance Services...................................................................103

8.13 Additional Managed Services Terms and Conditions...............................................................107

9 Managed Services Service Level Requirements...............................................................................114

9.1 Service Level Framework.........................................................................................................114

9.2 Service Level Specific Performance Credits..............................................................................114

9.3 Overall Contract Performance.................................................................................................117

9.4 Monthly Service Level Report..................................................................................................117

9.5 Service Level Review and Continual Improvement..................................................................118

9.6 Service Level Commitments.....................................................................................................118

9.7 Service Levels – User Experience.............................................................................................121

9.8 Service Levels – Security..........................................................................................................135

9.9 Service Levels – Governance & Compliance............................................................................138

9.10 Service Levels – Operations.....................................................................................................143

10 Shared Services Implementation SOW........................................................................................148

10.1 General....................................................................................................................................148

10.2 Project Management Requirements........................................................................................151

10.3 Technology/Finance Requirements.........................................................................................154

10.4 Change Management Requirements.......................................................................................164

10.5 Shared Services Estimating Assumptions.................................................................................176

10.6 Assumptions............................................................................................................................182

11 Shared Services Service Level Requirements...............................................................................183

11.1 Service Level Framework.........................................................................................................183

11.2 Service Level Specific Performance Credits..............................................................................183

11.3 Overall Contract Performance.................................................................................................185

11.4 Service Level Review and Continual Improvement..................................................................186

11.5 Service Level Commitments.....................................................................................................187

11.6 Service Levels – Software Development..................................................................................188

11.7 Service Levels – Testing Performance......................................................................................191

Page [4]


11.8 Service Levels – Project Performance......................................................................................195

11.9 Service Levels – Support of State Activities..............................................................................198

11.10 Service Levels – Development Methodology Compliance...................................................200

11.11 Service Levels–Project Delivery–Build/Test Activities as a Percentage of Overall Activities 201

11.12 Service Levels – Project Completion – Issues Detected and Resolved In Production...........202

12 Ongoing Project Services Requirements......................................................................................203

12.1 General....................................................................................................................................203

12.2 Ongoing Project Services Objectives........................................................................................203

12.3 Ongoing Project Services SOW.................................................................................................203

13 Ongoing Project Services Service Level Requirements................................................................213

13.1 Service Level Requirements.....................................................................................................213

13.2 Project Services Pricing Response and Rate Card....................................................................213

Page [5]


1 IntroductionThe State of Ohio has made a significant investment in developing and deploying a PeopleSoft application suite, including Finance (FIN), Human Capital Management (HCM), Enterprise Performance Management (EPM), initial elements of Enterprise Learning Management (ELM), and Customer Relationship Management (CRM).

They deployment of this suite was completed in July 2008 and is currently supported operationally by a combination of State employees and significant staff augmentation from third-party providers. The State intends to transform their current application support to a Managed Services model, governed by SLAs, in which the Contractor is ultimately responsible for the ongoing management and performance of these applications.

As a result of this initiative the State intends to:

Increase service levels and systems quality as well as quality and timeliness of operations; Access best practices and lower cost of operations to help the State achieve a higher level of

operational and cost efficiency; Create repeatable and predictable processes; Increase access to centralized financial data; Eliminate work/rework cycles as a result of manual efforts; Increase control over key business processes; Streamline operations; Reduce exposure to risk; Improve overall control over critical financial functions (e.g., GL, AP, billing / AR and fixed asset

accounting); Support the implementation and operation of on-going business process transformation activities; Position the State to scale operations in a cost-effective manner; and Increase the degree of system integration and automation.

While the above improvements are critical to success of the program, the current application suite has already delivered significant value to the State. This value has led the State to pursue the development and rollout of a Shared Services Center, supported by enhanced PeopleSoft applications, to deliver services to the various Agencies of the State.

In February 2008, the State issued an RFP for the Design and Implementation of the Ohio Shared Services Center (OSSC), initially to include Finance services and ultimately to include additional Shared Services (SS) capabilities such as Human Resources (HR).

As the Design Phase of this project is nearing completion, the State now wishes to solicit offeror responses to lead the implementation of the OSSC, which includes business/finance processes, change

Page [6]


management, communications, and technology components. Included within the technology component are significant modifications to the current PeopleSoft Financial Applications to support the new Shared Services requirements, integration with a new Imaging Services Provider, and implement the new PeopleSoft CRM application for the OSSC.

As the OSSC and PeopleSoft applications mature, the State anticipates the need for additional, large-scale Project work to develop new capabilities and enhance the existing application suite. To support these types of Projects, the State has also included requirements for Ongoing Project Services as part of this RFP.

Due to the significant overlap of PeopleSoft related requirements, the State has included the requirements for Managed Services, the OSSC Implementation, and Ongoing Project Services within this single RFP, to ensure an integrated and cohesive implementation and operation approach.

A high-level diagram of this RFP as it relates to these three service categories is included below:

Overall RFP Scope

Managed Services Shared Services Implementation

Ongoing Project Services Capability

PeopleSoft FIN, HCM, EPM,

ELM, CRM Major/Minor Upgrades Application and Infrastructure

Break/Fix Application Development &

Maintenance Production Operations Technical Infrastructure Operating Facility Required Service Levels

Statewide Capability Rollout Overall Program Management Facility/Capability Implementation Change Management & Training Process and Technology

Enablement

Technical Implementation New PeopleSoft Module

Implementation Enhancements to Existing Modules Required Service Levels

Ongoing PeopleSoft Evolution New Modules and Capabilities Major Future Initiatives Significant Architecture

Extension/Expansions

Foundational Terms Standardized Delivery Model Standardized Rate Card Governing SOW Expectations and

Defined SLAs

State/Contractor Governance Requirements

Standard Terms, Conditions, Requirements and Expectations

Page [7]


2 Current Situation Overview

2.1 Services Areas

2.1.1 Managed ServicesThe State has recently completed a review of several operational systems associated with the support of its PeopleSoft Human Capital Management (HCM) system, Financial Systems (FIN) and Enterprise Performance Management (EPM) data warehouse and developed a strategy designed to transform and enhance the current operational capabilities of these systems. In particular, the State’s support systems have the following dynamics that the Offeror must be in a position to address and enhance:

Increase the State’s capabilities by deploying high impact and cost effective systems and systems management capabilities;

Differentiate the State wherever possible by providing unique offerings to State employees and State constituencies while providing best-in-class operational performance and capabilities;

Support the migration of services to a reliable, repeatable and world-class set of operating capabilities, standards and methods that are delivered in a cost effective and predictable manner;

Create a platform that is designed to drive overall consistency of operations through the leverage of common systems platforms, consistent business processes and deploying/leveraging best practices wherever possible; and

Work with the State to implement modern operating capabilities, delivered under contemporary standards such as ITIL, software and Testing Capabilities Maturity Model (CMM) and structured software development/implementation methodologies to ensure overall quality, operational agility, and alignment with supporting future requirements of the State in a reliable and cost-effective manner.

PeopleSoft is currently deployed in support of key Financial and Human Resources transaction management activities within the State. The following is a high-level timeline of the major PeopleSoft implementations to date:

Page [8]


Dec. 2006 March 2007 July 2007 Jan. 2008 July 2008

Human Capital Mgmt(HCM 1)

• Core HR• Payroll• Time & Labor• Base Benefits• EPM• HR2K Data

Warehouse


• Benefits Administration

• eBenefits for open enrollment

• COBRA• EPM

Finance (FIN 3)• Purchasing• General Ledger• Accounts Payable • Accounts

Receivable• eProcurement • EPM• CAS Data

Warehouse


• Year end T&L pilot• EPM

Finance (FIN 5)• Year-End

ProcessingBilling

• EPM

Finance (FIN 6) • Asset

Management • Budgeting and

Planning• EPM

Impl

emen

tatio

ns

•

There have been several benefits delivered to the business as a result of the PeopleSoft implementation. The following is a summary of benefits realized to date:

Page [9]

Implemented Project Level Objectives

Realized Benefits

HCM Release 1 - Core HR, Payroll, Base Benefits, Time and Labor, ePay, Enterprise Performance Management (EPM) for HCM modules, HR2K Data Warehouse

HCM Release 2 - Benefits Administration, COBRA, eBenefits(open enrollment only), EPM for Benefits Administration and COBRA

FIN Release 3 - Purchasing, General Ledger, Accounts Receivable, Accounts Payable, eProcurement, EPM for FIN modules, and the CAS Data Warehouse

HCM Release 4 - Year End Processing, Time & Labor SS Pilot, and eBenefits

FIN Release 5 - Billing

FIN Release 6 - Asset Management, Budget and PlanningPayroll Modeling

• Eliminate redundant system efforts.

• Consolidate and streamline business practices and administrative processes.

• Implement advanced functionality such as e-government “self -service” Web applications.

• Leverage the technical capability of commercial -off -the-shelf (COTS) software packages that are regularly updated by industry leading software vendors.

• Provide an integrated system with consistent non -redundant data that serves as a cohesive foundation for eventual add-on capabilities.

• Conserve agency resources by replacing dated legacy systems and reducing the need for custom -built systems.

• Improve and integrate the centralized business system environment to support major administrative functions.

• Automate paper -based manual processes.

• Improved Decision Making -Provide a consolidated and consistent view of statewide information, specifically through cross functional integration of information and the use of business intelligence tools.

• Increased Efficiency - The process redesign inherent in implementing an ERP system presents an opportunity to examine and adopt best practices. These best practices can be rapidly integrated into the State’s business process to achieve efficiencies that support the State’s overall goals and objectives.

• Improved process integration and controls -Improved process integration and control benefits are primarily derived from the integration of the various functional areas into one system.

• Improved service levels - OAKS will establish the foundation for sustainable e -government which refers to the integration of people, business processes, information, technology, State government programs, and policy to achieve dramatically new, multi -channel approaches to government service delivery.

• Avoided costs of the status quo - Avoiding ongoing costs associated with operating and maintaining the existing central and agency systems, as well as making potential investments in enhancing existing systems


This RFP is designed to receive responses for services that will allow the State to continue driving efficiencies with respect to ongoing operations, continued extension of the system and its use, refinement of the overall cost to operate and manage; as well as drive higher levels of service for the users and beneficiaries of the system.

2.1.2 Shared Services ImplementationThe main objective of the OSSC is to standardize and streamline business processes using best business practices, enabling technologies, and workflow management. Efficiencies resulting from this Project will assist the State in managing its finances and will help alleviate forecasted staffing shortages in the years ahead.

An RFP for the Design and Implementation of the OSSC was issued in February 2008, of which the Design Phase will be concluded in the coming months. The Design Phase focuses on:

Establishing the new organization structure; Determining the resources required to support the in-scope financial processes; Documenting the facility requirements; Establish clear stakeholder communications and a change management processes; Creating the process and technical designs; and Identifying the training needs of impacted organizations, individuals, and vendors.

All tasks and activities related to the Design Phase are scheduled to be completed at the start of the Build Phase. The State believes it is well positioned to begin the Build Phase for the desired scope and services in the Shared Service Center, as well as roll-out the OAKS functionality to support the new finance business processes.

The State has the following objectives that it would like to fulfill via the Ohio Shared Services Project (OSSP) and it will be the Contractor’s obligation to ensure that the Project meets these high-level objectives:

Implement the redesigned and standardized statewide Finance processes, leading to lower costs to the State;

Manage the creation of a single statewide business call center capability for vendor inquiries, including organization design, process mapping and training;

Improve access and timeliness to management information; Create scalable processes to handle future business requirements as well as increased volume

as additional agencies are brought on line; Define clear expectations for the State’s employees in the OSSC related to job responsibilities,

processes and policies; and Build an organizational foundation where the State can migrate other administrative services to

in the future.

The Build Phase will implement the infrastructure and technology to have specified statewide Procure to Pay, Record to Report, and other functions delivered by a single Shared Services organization. The OAKS

Page [10]


system and future enabling technologies will support the end-to-end process and act as a single source of data to the enterprise.

2.1.3 Ongoing Project ServicesThe State anticipates the need for additional, large-scale Project work to develop new capabilities and enhance the existing application suite, though in many cases these Projects have yet to be defined. The State seeks to create a structure through which these Projects can be procured in a timely fashion and in accordance with best practices in both application development and project management.

Future plans for the PeopleSoft environment are listed below to better inform offerors with respect to ongoing projects, development, maintenance and operations activities.

Legend:

T&L : Time and Labor CI: Capital Improvements CR: Change Request HD: Help Desk OIT: Ohio Office of Information Technology OAKS: Ohio Administrative Knowledge System SS: Self Service

Page [11]


3 High Level Scope of Services

3.1 RFP OverviewThe State is requesting offerors to reply to three segments of work that are aligned around 1) current requirements for the ongoing operation and maintenance of existing PeopleSoft applications in a Managed Services environment; 2) full Project ownership to complete the build and production implementation of the Ohio Shared Services Project (OSSP) including technology, process, and change management components; and 3) creation of an ongoing PeopleSoft Project delivery capability that is designed to provide the State with capacity to address significant Projects on an ongoing or future basis.

3.2 Managed Services High Level ScopeA framework has been provided to better inform the offerors of the overall scope of the Managed Services portion of this RFP. Specific details as to the technical, process and organizational impacts of this Project as well as key statements of work, desired roles and responsibilities, required service levels, State/Contractor governance structures and other key requirements and concepts are contained in this RFP. While the detailed responsibilities of State and Offeror/Contractor are contained in each SOW in this document, the high level Managed Services Framework, which is indicative of both Contractor and State responsibilities, is outlined below.

Page [12]


Within the major facets of this framework, corresponding functional areas have been defined. Those items highlighted in grey below are included in the scope of services requested via the Managed Services portion of this RFP. The items highlighted in blue will be retained by the State.

As mentioned above, this is a high-level overview provided to clarify offerors’ understanding of the desired services. Detailed requirements are included in the appropriate sections of this RFP.

The high level working structure between State business owners, the anticipated State Managed Services Organization, and the Contractor is depicted below:

Page [13]


OAKS Program Director

FIN Service Assurance

Level 1 Help Desk

PMO/Vendor Mgmt

BI/Strategic Reporting

Service Assurance

Chief Security Officer

HCM Service

Assurance

OBM/GSD Business Process Owners

HRD BusinessProcess Owners

Managed ServicesVendor

GovernancePerformance Mgmt

Financial Mgmt

SLAs SOWs Transparency

Managed Services Contractor

Based on this structure, the State will retain certain key roles and responsibilities designed to drive overall services, alignment with business strategy and objectives, include service quality/assurance considerations as well as setting the overall direction for the program. These retained functions are outlined below:

Page [14]


Managed Services Provider Teams Provide Services as outlined in this RFP

Managed Services Providers

The Business Process Owners will have the following roles and responsibilities:

Process Owners Roles and Responsibilities Primary Interface to/from OAKS HCM and FIN Service

Assurance Groups

Lead Requirements Analysis and Documentation

Review/Approve Designs (Functional, Implementation, Technical, Operations and Process)

Lead Business Prioritization of Break/Fix and Discretionary

Business Process and Quality Standards

Liaison w/User Community, End-User Expectation Management

Coordinate UAT w/Business Representatives

Business Event Analysis

Participation on Major Business Initiatives and Projects

SLA/Performance Review and Adjustment

Participate in Statement of Work Review, Amendments and Approval

Participation in Overall Program/Contract Governance

Business Escalation Point for Service Provider to Resolve Level 2/3 Problems

OBMProcess Owners AP GLAR/BI B&P

HRDProcess Owners HRPayroll BenefitsT&L Base HR

GSDProcess Owners PO AM

The Service Assurance Teams will have the following roles and responsibilities:

Page [15]


In addition, the State will also provide Infrastructure Service Assurance, per the roles and responsibilities defined above.

3.3 Ongoing Project Services ScopeIn high-level terms, Managed Services includes day-to-day operations of the PeopleSoft applications, from the IT infrastructure/hosting to application administration, reporting, and support, as well as both major and minor PeopleSoft related system enhancements and projects. Ongoing Project Services includes the design, development, testing and deployment of new applications or significant application enhancements that may or may not be PeopleSoft related. Upon completion of a Project Services implementation, the completed application, once meeting the State’s acceptance criteria, will be managed on an ongoing basis as a Managed Service.

To convey the context of the Managed Services offering as it pertains Project Services (as part of the OSSP or future Projects) the following diagram lists representative activities within each service type and illustrates how these two service types will relate to one another. In addition, the diagram shows the various activities which will be retained by the State, which apply across both Managed and Project Services.

Page [16]


Contractor ResponsibilitiesManaged Services

State Responsibilities

Project Services

Steady State Operations and Maintenance Services

Service Desk System/Environment Administration

Support Environment Preventive

Maintenance Ad-Hoc Requests Minor Enhancements to Software IT Network Connectivity/Monitoring

Applications / Implementations (Current)

Human Capital Mgmt

FinanceEnterprise

Perf.Mgmt

Data Warehouse

Finance Shared

Services

Finance Shared

Services

(Future)

Steady State Operations and Maintenance Services

Service Desk Environment

Technical Support System/Environment

Administration Transition Services

Managed Hosting Systems Management and

Administration Security Services Infrastructure

Management Services Program Management

New or Major Enhancement

(e.g., FIN Upgrade for

Shared Service)

Administration

Governance

Strategy

Standards

Sample Activities Managed Hosting Security Services Infrastructure Mgmt Program Management Incident Management Quality Assurance Solution Documentation Disaster Recovery SAS-70 Audit Reporting

Invoice Payment Communication Knowledge Transfer Management

Steering Committee Oversight Financial Management Performance Management

(SLA Compliance, KPI, Dashboard Review, etc.)

Requirements Analysis Requirements Definition Change Management Architecture Application Selection

User Acceptance Testing Service Delivery Auditing Disaster Recovery Standards

Sample Activities

3.4 Shared Services Implementation ScopeThe offeror selected for the Shared Services Implementation will be responsible for implementing the Build Phase of the OSSP and managing the roll-out that will create the OSSC. While the State expects the OSSC model to eventually be expanded to provide HCM functionality including Payroll, the current scope is only for FIN and the related financial processes.

The following diagram depicts the major threads and the high-level scope, impact, and outcomes expected of Shared Services.

Page [17]


Shared Services Implementation

Technology / Finance Change Management

Project Management

• PeopleSoft Technical Implementation

• Technical Project Management of Enabling Technology Roll-out

• Development of KPI and SLAs between OSSC and Agencies

Creating and distributing communication materials with content direction from the State

Ensuring common understanding of program and value Training development, delivery, logistics, environments,

data sets, and post-training responsibilities Agency Readiness and Change Management OSSC Readiness and Change Management

Maj

or Th

read

sIm

pact

/Out

com

e

OAKS/OIT State Agencies Shared Services

PeopleSoft and enabling technology implemented

and transitioned to Managed Service

Provider

State Agencies trained and transitioned to

Shared Services

Shared Services processes in place and

running as required

3.4.1 Current Shared Services Project StructureThe Build Phase consists of professional and consulting services to validate, manage, and execute the development and implementation of the Shared Services Center as outlined by the SOW.

The Contractor will serve as the prime implementer for the OSSP. The table below lists the general responsibilities of each thread of the Project.

Task Area DescriptionProject Management Overall Project management, reporting, issue management, etc., including

Project management of the implementation of the enabling technologies to support the OSSC

Technology/Finance Implementation of PeopleSoft Financials build work, new implementation of PeopleSoft CRM, overall technical Project management including technologies being built within the OSSC, development and application of KPIs, complete Finance end-to-end testing

Change Management Change management, communication, training, roles and role descriptions, implementation of designed finance processes for the OSSC, including overall design testing and validation process

Page [18]


4 Required Differentiators

4.1 Offeror Required Differentiators and Qualifications The State welcomes offerors to provide brief overviews of their capabilities, core competencies, and market differentiators in the following areas:

Oracle/PeopleSoft Relationships, Alliances or Awards that demonstrate a commitment to PeopleSoft and a long-standing track record of successful deliveries and customer experiences;

Significant Customer Testimonials that highlight the strength of partnership between the offeror and their customers that have resulted in achieving the strategic goals of your customers, specifically with respect to large government entities and in the area of Shared Services implementation;

Access to Best Practices that the offeror has developed with customers that result in rapid, high quality and low cost operational usage of PeopleSoft modules while mitigating needs to customize the system;

World-Class Support Capabilities that drive the highest levels of support and service that ensure maximal usage and availability of the system – particularly during critical financial periods, but also during routine or planned maintenance and enhancement periods that minimize disruption to business and user communities;

Commitment to Scalable, Upgradeable Solutions to ensure the State has access to current features/functionality and can pursue migrations and new service implementation in a timely and cost effective manner;

Commitment to Minimize Customization and maximize the value provided by the standard off-the-shelf PeopleSoft modules, given the various requirements of the State;

Innovative Practices and Methodologies provided by the offeror that are market proven and help drive successful migrations, implementations and enhancements while mitigating Project risk wherever possible;

PeopleSoft Center of Excellence or “laboratory” type of environment where best practices and methodologies are designed and refined in the context of new PeopleSoft capabilities, releases, versions or modules;

Rapid Implementation and Quality Methodologies designed to help ensure that migrations and implementations go as quickly as possible, are reviewed at each major step against quality requirements, and result in minimal business interruptions, auditable performance, and a lasting operational capability that the State can build on; and

Development of long-term partnerships working with public sector and government entities, establishing mutually beneficial, long term relationships.

Page [19]


4.2 Other Key DifferentiatorsThe State welcomes offerors to share their demonstrated capabilities in the following areas that, for purposes of this response, are specifically out-of-scope, but may be required in the future:

Additional PeopleSoft module implementation services; and Related PeopleSoft application configuration, deployment and management services that may

include reporting databases, performance tuning and management, operational/ongoing cost reduction projects, end-user rollout/training and other PeopleSoft related activities.

4.3 Foundational ConceptsThe State has several foundational concepts that have been developed to guide the overall program and shape the desired delivery model to serve the State and its constituencies and partners. The following table outlines these foundational concepts:

Foundational Concept Overview and Details

Create accurate and timely reporting

The State of Ohio is a large-scale institution with a correspondingly complex ERP system. The mandated need for accurate, timely processing and reporting requires that the system be managed and controlled effectively at an enterprise level.

Communicate clearly across customers

It is important to recognize that the OAKS Program comprises more than just the OAKS IT organization. It also includes the key business organizations (e.g., DAS GSD, DAS HRD, OBM) collectively responsible for ensuring overall success.

Retain/develop knowledge capital

There is a strong desire and keen focus to retain knowledge capital within the State, specifically in areas that drive strategic value. This guiding philosophy must be weighed against any risks that prevent the State from fulfilling its mission.

Leverage current OAKS

platform/investment

While steady-state stability is a necessity, the current OAKS platform will be leveraged and expanded in perpetuity to meet the State’s evolving needs (e.g., shared services, procurement reform, EPM) and to maximize the State’s return on its initial IT investment.

Create support model which will enable future initiatives

The OAKS “enterprise” operating model provides a foundation, framework and roadmap for future statewide IT initiatives (e.g., HR Shared Services).

Enable service delivery to meet the

needs of State

OAKS must enable service delivery excellence in support of current and future State agency needs.

Fiscal responsibility On-going investment in the OAKS program must provide tangible value of the highest marginal benefit to system users and the citizens of the State.

The State welcomes offerors to share their capabilities and ability to perform services in a manner consistent with these concepts.

4.4 Information Technology Infrastructure Library (ITIL)The State requires that the Contractor implement principles which will help the State move towards Information Technology Infrastructure Library (ITIL) compliance. It is therefore required that the Contractor adopts a set of ITIL compatible concepts and techniques for managing the State infrastructure and operations.

Page [20]


The ITIL discipline is to be focused on providing the appropriate Services to support the following areas.

The Service Desk handles all in scope services incidents, problems and questions as well as providing an interface for other activities such as change requests, maintenance contracts, software licenses, Service Level Management, Configuration Management, Availability Management, Financial Management, Application Management, and IT Services Continuity Management for Level 2 for the supported Servers, LAN, and Storage Devices connected to the servers; and Levels 2 and 3 for vendor hardware supporting the Servers, Storage Devices and LAN.

Incident Management process and procedures will be in place and continually refreshed in order to have the capability to restore a normal service operation as quickly as possible and to minimize the impact on business operations. An incident is considered to be any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.

o The objective of the incident management process is to:

Restore normal operations as quickly as possible with the least possible impact on either the business or the user, at a cost-effective price; and

Maintain a comprehensive inventory of 'known problems' (without a known root cause) or 'known errors' (with a root cause) under the control of Problem Management and registered in an error database;

o Processes and procedures are to include:

Incident detection and recording;

Classification and initial support;

Investigation and diagnosis;

Resolution and recovery;

Incident closure; and

Incident ownership, monitoring, tracking and communication.

Problem Management is the process for identifying, recording, tracking, correcting and managing problems impacting service delivery, recognizing recurring problems, addressing procedural incidents and containing or minimizing the impact of problems that occur. Problem Management processes will be used to find and resolve the root cause of incidents to minimize the adverse impact of IT infrastructure incidents and problems on the State and to prevent recurrence of incidents related to these errors.

o The objectives of the problem management process are:

Page [21]


Reduce the number and severity of incidents and problems on the business, and report it in documentation to be available for Level 1 (State operated) and Level 2/3 (Contractor operated) of the Service Desk; and

Provide a proactive process that identifies and resolves problems before incidents occur.

o Activities include:

Problem identification and recording;

Problem classification;

Problem investigation and diagnosis;

Identification of the root cause of incidents;

Trend analysis;

Initiation of targeted support action;

Providing information to the organization; and

Iterative processing to diagnose known errors until they are eliminated by the successful implementation of a change under the control of the Change Management process.

Configuration Management is the process for designing, planning and maintaining the physical and logical configuration of Supported server hardware and Systems software as well as network components and the way these resources are interrelated in the State environment. It consists of process and database tools that track all of the individual Configuration Items in the State service catalog for the supported devices (e.g., servers, LAN and storage devices). Basic activities include:

o Planning: The Configuration Management plan covers the next three to six months in detail, and the following twelve months in outline. It is reviewed with the State at least twice a year and includes strategy, policy, scope, objectives, roles and responsibilities, the Configuration Management processes, activities and procedures, the database, relationships with other processes and Third Parties, as well as tools and other resource requirements.

o Identification: This covers the recording of information including hardware and software versions, documentation, ownership and other unique identifiers. Records are maintained in a Configuration Management database covering the selection, identification and labeling of all configurations of every item in the Contractor provided infrastructure and systems.

Page [22]


o Control: This only accepts and records authorized and identifiable Configuration Items from receipt to disposal. The Contractor provided infrastructure and systems are under Change Management control.

o Monitoring: Accounting and reporting on all current and historical data concerned with each Contractor provided item throughout its life-cycle. It enables changes to items and tracking of their records through various statuses, e.g. ordered, received, under test, live, under repair, withdrawn or for disposal.

o Verification: Provide reviews and audits that verify the physical existence of items, and checks that they are correctly recorded in the Configuration Management database. It must also include the process of verifying Release Management and Change Management documentation before changes are made to the State live environment.

Operational Services processes describe the daily activity which delivers service from the use of the infrastructure, Applications and Services in order to meet Service Level Agreements and business targets for the server devices (e.g., servers, LAN Devices, Storage Devices and software) for those environments for which the Contractor is providing Services. This collection of processes senses and responds to day to day fluctuations that occur in order to provide as much of the committed service as possible. This collection represents the day to day service operations within IT. This includes managing contact with Users. Services include data and storage management, event management, incident management, problem management and service execution.

Page [23]


5 Required Operating Environment

5.1 GeneralThe State is currently a user of PeopleSoft systems and related services, operated out of the State Office Tower (SOT) and the State Operations and Computing Center (SOCC).

The State maintains offices across the State and has user constituencies in these locations. For purposes of this RFP, the State FIN, EPM, CRM, ELM and HCM systems and related reporting are the key user constituencies for the scope of the PeopleSoft system and related Managed Services.

The State may continue to define and refine the operations and use of PeopleSoft in the future. The State may choose to revisit the deployment strategy for PeopleSoft with respect to State functions and offerings either provided by the Contractor or supported by the systems contained herein.

As part of this initiative, the State would like to obtain higher service and quality levels for systems that support the State’s financial consolidation and analysis, transaction processing, control of key processes that support the State’s business and provide robust automated information flows of critical financial information.

5.2 Operational and Strategic ObjectivesAs part of this RFP, the State has several operational and strategic objectives, including:

Increased service levels and systems quality as well as quality and timeliness of operations; Access to best practices and lower cost of operations to help the State achieve a higher level of

operational and cost efficiency; Access to repeatable and predictable systems management capabilities such as standard

maintenance, system patches, upgrades in conjunction with robust system testing/certification capabilities for new system software that allow the State to be more agile and take advantage of new technology as the State’s needs require;

Access to “Project expertise” on an as needed basis to assist in the design, development and deployment of new PeopleSoft modules or deployment of PeopleSoft capabilities when deemed required by the State’s business model;

Increased access to centralized financial data that eliminates wherever possible work/rework cycles as a result of manual efforts;

Ability to utilize more robust financial management system functionality that drives a higher level of integration and consistency in the State’s day-to-day operations;

Increased control over key business processes, streamlining of operations and removal of risk exposure areas where possible;

Greater control over critical financial functions (e.g., GL, AP, billing / AR and fixed asset accounting) while positioning for scaling of the State’s operations in a cost-effective manner; and

Page [24]


Increased system integration and automation around reporting to reduce manual work and reliance on non-automated systems and processes.

Pertinent Technology Strategy Elements are as follows:

The State wishes to invest in technology elements that drive effectiveness with regard to delivering a high quality and lower cost service, but with high value to State employees and the public;

The State’s philosophy in this area is to develop and retain as much intellectual property as possible in areas that directly touch both the constituents and State employees, and make a marked difference in their experience and relationship with the State;

The State will focus on areas that drive and enhance the value delivered to the constituents and the ability to respond to the demands of the public;

The State will retain external Contractor(s) to provide technology services where it makes the most sense for the business (e.g., hosting, operations and elements of application management) and allow the State to be more nimble and operate with a lower cost structure;

The State will invest in and grow internal skills that drive effectiveness and delivery of high quality systems and services to both external and internal stakeholders;

The State would like the Managed Services Contractor to work collaboratively to evaluate, implement, maintain and enhance additional PeopleSoft modules and capabilities, specialized reporting and data extraction for Business Intelligence and generally ensure that the State’s systems capabilities are world-class; and

The State plans to increase standardization where possible and when advantageous to the State’s cost position and in support of the State’s mission and public remit.

Specific capabilities that the State wishes to develop and leverage with the Contractor are as follows:

Business Needs Execution Mechanisms

Tale

nt/P

eopl

e

Reduce costs to support PeopleSoft operations and support while maintaining a positive ROI

Obtain longer-term rate cards from key support Contractor

Competitively procure services to ensure market rates for these services

Controlled processes to limit customizations

Leverage of skilled internal resources / knowledge workers

Train State resources in various areas through additional networking, training and support from Subject Matter Experts

Drive operational and technical consistency across divisions/agencies

Enable/develop repeatable processes with clear expectations, outcomes and staffing/skill requirements

Page [25]


Proc

ess

Process transactions with high levels of repeatability and predictability

Create and apply a process and performance framework based on incentives, implemented and managed aggressively

Drive high-levels of process automation and eliminate manual activities / dependencies wherever possible

Utilize world-class methodologies to drive development, testing and overall operations and maintenance of existing and future systems

Increase the overall quality of documentation for key technology and operational elements

Enforce adherence to process principles and require staff to update materials that are most utilized and valuable.

Implement clear escalation paths and root cause analysis to increase the repeatability of operations

Implement detailed process flows to help eliminate operational gaps and issues

Ensure that the required compliance elements are met

Provide stabilized system that user communities can both trust and rely on

Meet security/risk requirements Create Disaster Recovery (DR) plans Perform regular DR testing

Reduce the overall degree of customizations to the PeopleSoft environments

As new functionality is implemented, remove portions of obsolete or non-compliant code through careful planned processes

Tech

nolo

gy

Develop an application roadmap that can meet the current and anticipated future business needs

Ensure longer term State and agency needs are considered as part of an overall strategy and in consideration of future PeopleSoft offerings.

Implement/optimize reliable processes and redundancies for High Availability

Prioritize DR planning for functional and technical staff within OAKS.

Perform mandatory, complete dress-rehearsal every year.

Obtain Tier III data center and implement ITIL® processes.

Implement a defined asset management process

Develop licensing requirements as part of an overall IT strategy.

Drive centralized application management, operations and decision making

Ensure the current application suite is fully functional and move agencies to fully integrate into current systems – especially in the case of the Data Warehouse

Page [26]


5.3 Data Center Environment and Personnel RequirementsThe State requires all systems to be housed in a secure Tier III or superior (as specified by the UpTime Institute http://www.uptimeinstitute.org/ Tier Performance Standards) environment, in keeping with the State’s Disaster Recovery guidelines, including:

temperature controls and cooling to prevent failure due to environmental reasons; electrical power redundancy with alternative power availability from both redundant power

grids and on-site electric generators; sufficient uninterruptible power capability to facilitate the continuous operation and availability

of the system in the event of a power failure; continuous monitoring for electrical, cooling and environmental issues that could adversely

impact operations; a disaster recovery site that offers similar operational capabilities as the primary site; a disaster recovery site with consistent attributes to the primary data center facility with regard

to redundancy, monitoring, environmental considerations; transfer of operations to disaster site to occur in accordance with defined service levels upon

failure of primary site; transfer of State data, configurations and user access to this site is to occur in accordance with

defined service levels upon failure of the primary site; geographic diversity from primary processing site; restoration of primary operations site operations (once available) within defined service levels;

The Contractor shall comply in all respects with U.S. statutes, regulations, and administrative requirements regarding its relationships with non-U.S. governmental and quasi-governmental entities including, but not limited to the export control regulations of the International Traffic in Arms Regulations (“ITAR”) and the Export Administration Act (“EAA”); the anti-boycott and embargo regulations and guidelines issued under the EAA, and the regulations of the U.S. Department of the Treasury, Office of Foreign Assets Control.

The Contractor will provide resources for the work described herein a natural person who is a lawful permanent resident as defined in 8 U.S.C. 1101 (a)(20) or who is a protected individual 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 or taking any State information including data, software, code, intellectual property, designs and specifications, system logs 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.,

Page [27]

http://www.uptimeinstitute.org/


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.

Where the Contractor is handling confidential employee data associated with Human Resources data, the Contractor will comply with data handling privacy requirements associated with HIPAA and as further defined by The United States Department of Heath and Human Services Privacy Requirements and outlined in http://www.hhs.gov/ocr/privacysummary.pdf

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.

Where the Contractor is handling confidential employee data associated with Human Resources data, the Contractor will comply with data handling privacy requirements associated with HIPAA and as further defined by The United States Department of Heath and Human Services Privacy Requirements and outlined in http://www.hhs.gov/ocr/privacysummary.pdf. In addition, the Contractor will be required to sign the Business Associate Agreement included in Supplement Eight.

Page [28]

http://www.hhs.gov/ocr/privacysummary.pdf


6 Current Technical Environment Overview

6.1 General Based on the modules implemented to date, a high-level context is as follows, please note that the State Finance, EPM, HCM, ELM, CRM and reporting systems will run in one “Business Environment” due to the fact that configurations, customizations, operational considerations are similar.

Offerors must propose an end-to-end Managed Service including the hosting, ongoing management and maintenance, including deployment/management, testing and training environments for the instances of the PeopleSoft modules and supporting applications identified in this document. The table below reflects the State’s requirements in terms of environments. To the extent the offeror wishes to suggest alternatives, the offeror may do so in their response to this section.

PeopleSoft Environments Supporting Applications

Application HCM FIN EPM CRM ELM UC4 ITG CognosDemo ü ü ü ü ü

Patch Testing/Staging ü ü üDevelopment ü ü ü ü ü ü üConfiguration ü ü ü ü üQuality Assurance/ Testing ü ü ü ü ü ü ü ü

Page [29]


Performance Testing ü ü üProduction ü ü ü ü ü ü ü üTraining Development ü ü ü üTraining Delivery ü ü ü üTraining Practice ü ü üProof of Concept ü ü ü

Descriptions of the instances are as follows:

Demo: This is the instance delivered by PeopleSoft for diagnostic purposes. All patches and bundles will be applied to this instance. No customizations, modifications or configurations will be made to this instance.

Patch Testing/Staging: This instance is for developers to test PeopleSoft delivered bundles and fixes.

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

Configuration: This is the instance used to test and validate large-scale configuration changes to the HCM environment. Configuration changes for the other applications are made in other environments.

Quality Assurance: This instance allows testers and pilot users to test the customizations, modifications or configurations made to the application before any changes are migrated to Production. This instance will be used for User Acceptance Testing and all forms of integration testing.

Performance: This instance allows testers and pilot users to assess production performance issues and for performance testing.

Production: This is the main transactional instance. Training Development: This is used to create training scenarios. Training Delivery: This instance is used for classroom and web-based training. Training Practice: This instance is used to practice for classroom and web-based training. Proof of Concept: This instance is used for exploratory development and product testing.

Please note that instances required by the Contractor to support pre-production implementation and migration staging, production or disaster recovery validation, additional processing requirements for peak or seasonal requirements or infrastructures for performance testing as described in the Managed Services SOW (Section 8) will be the requirement of the Contractor to provision and provide as required by their operations and to adhere to the specified Service Level Agreements outlined herein, in keeping with contemporary high availability fault-tolerant configurations as required by the specified Service Level Agreements.

The following table provides high-level estimates of the number of concurrent users/developers where available.

Supported Instance Estimated Number of Concurrent Users/Developers and Profile

Page [30]


Demo Offerors to propose environment and capabilityPatch Testing/Staging Offerors to propose environment and capabilityDevelopment Offerors to propose based on development resource compliment

required to deliver the Managed and Shared Services Statements of Work contained herein

Configuration Offerors to propose environment and capabilityQuality Assurance/Testing 15-25 end users, plus any Contractor support staff, provisioned

coincident with and preceding UAT commencementPerformance Testing Offerors to propose based on scope of testing effort based on the

Statements of Work contained herein, though generally not applicable except for online performance tests where Mercury LoadRunner will be used for simulated load testing.

Production Per module: HCM (Named: ~65,000, Max connected < 30,000 (seasonal)) Finance (Named: ~20,000, Max connected < 750) EPM (Named: ~80,000, Max Connected <250) ELM (Future State: Named: ~65,000, max connected < 5,000) CRM (Named: <250, Concurrent < 100)

Training Development Currently 15-25, will expand to ~150Training Delivery Currently 15-25, will expand to ~150Training Practice Offerors to propose environment and capabilityProof of Concept Offerors to propose environment and capability

6.2 Processing Profile Key StatisticsBased on recent transactional statistics for major elements of the FIN, HCM and EPM system the following table is presented to convey the approximate transaction load and cycle processing volume statistics (note that this is not a comprehensive listing of every transaction processed by the system).

Application Module Metric NumberFIN AP Peak vouchers in 24 hour period

through batch250,000 vouchers

FIN AP Peak payments to run through pay cycle in 24 hours

250,000 payments

FIN AP 1099s processed per year 17,500FIN AP # of active vendors 100,000FIN GL Peak # of journal lines per day ~200,000FIN PO Peak POs per day ~1500FIN AR Items processed per year ~125,000 FIN BI Bills per year < 50,000FIN AM Assets < 250,000HCM Payroll Pay cycles per month Bi-weekly (< 75,000 employees)

Monthly (< 5,000 employees)HCM Time and Labor # of employees entering time via PS 40,000 when T&L rolled outEPM Planning and

BudgetingPeak # of active cost centers < 750

CRM IT Helpdesk Average Open Cases <500

Page [31]


ELM N/A Number of Instructors Current: ~10-20 Future: Approximately 200

6.3 Current Hardware Configurations

6.3.1 Non Production EnvironmentsThe following table reflects the State’s non-production environments and current disaster recovery architecture, hosted at the State Office Tower (SOT):

Server Specification QtyHost

NamesOperating

SystemDatabase:DR

RP74208 x 1.0 GHz PA8900 CPUs24 GB RAMMirrored 146 GB internal drives2 x PCI Fibre Channel adapter cards6 x 1Gb Ethernet ports

2 oakdrdb1,2

HPUX Unix11.23

Database:Dev


2 oakdvdb1,2 HPUX Unix11.23

Database:Backup


1 oakbck1 HPUX Unix11.23

Application DL5858/4 x 2.2 GHz AMD 85012/6 GB RAMMirrored 72 GB internal drives

7 oaksdrapp01-5oaksdvapp01,2

Microsoft Windows 2003

Web DL3852 x 2.2 GHz AMD 2753 GB RAMMirrored 72 GB internal drives

4 oaksdrweb01,2oaksdVweb01,2


File DL3852 x 2.2 GHz AMD 2753 GB RAMMirrored 72 GB internal drives

4 oaksdrfile01,2oaksdvfile01,2


Ops DL3852 x 2.2 GHz AMD 2754 GB RAMMirrored 72 GB internal drives

1 oaksdrops01 Microsoft Windows 2003

6.3.2 Non Production Storage ConfigurationThe following table reflects the State’s storage, hosted at the State Office Tower (SOT):

Page [32]


Item SpecificationHostNames

Power Consumption(KVA)

Heat Output (BTU)

Storage Array

EVA 5000 2C2D24 x 146GB 10,000 RPM fibre channel disk drives in two trays Not named 7000 x 1 8600 x 1

Storage Array Configuration Server

DL3801 x 3.6 GHz Intel 370/380 G4 CPU4 GB RAMMirrored 72 GB internal drives cinsanserver01 750 x 1 2500 x 1

Backup

Tivoli Storage Manager(Service provided by development on a variety of equipment) N/A N/A N/A

Fibre Channel switches Brocade Storageworks 2/16 Two (2) Devices N/A N/A

6.3.3 Quality Assurance and Production HardwareThe following table reflects the various hardware required to host the State’s Quality Assurance, Performance and Production environments. This is currently hosted at the State of Ohio Computing Center (SOCC).

server Specification QtyHost

NamesOperating System

Database:Production

RP74208 x 1.0 GHz PA8900 CPUs24/32 GB RAMMirrored 146 GB internal drives2 x PCI Fibre Channel adapter cards6 x 1Gb Ethernet ports


3

1

pdb1pdb2pdb3

Pdb4

HPUX Unix11.23

Database:QAS


RP74208 x 1.0 GHz PA8900 CPUs32/48 GB RAMMirrored 146 GB internal drives2 x PCI Fibre Channel adapter cards6 x 1Gb Ethernet ports

2

1

qdb1qdb2

qdb3

HPUX Unix11.23

Database:General

DL5854 x 2.2 GHz AMD CPUs12 GB RAM2 x PCI Fibre Channel adapter cards4 x 1Gb Ethernet ports

1 pmonitor1 Microsoft Windows 2003

Page [33]




Backup RP34402 x 1.0 GHz PA8900 CPUs24 GB RAMMirrored 146 GB internal drives2 x PCI Fibre Channel adapter cards

2 pbackup1,2 HPUX Unix11.23

Application DL5858/4 x 2.2 GHz AMD 85012/6 GB RAMMirrored 72 GB internal drives

DL3852 x 2.2 GHz AMD 2754-6GB RAM(range of RAM for servers)Mirrored 72 GB internal drives

BL4858 x 2.4GHz AMD 85012 GB RAMMirrored 146 GB internal drives

11

6

papp1-7qapp1-4

papp8-10

papp11-16


Web DL3852 x 2.2 GHz AMD 2754GB RAMMirrored 72 GB internal drives

11 Pweb3,4,5,7qweb1-4


File DL3852 x 2.2 GHz AMD 2754 GB RAMMirrored 72 GB internal drives

4 pfile1-2qfile1-2


Operations DL3852 x 2.2 GHz AMD 2754 GB RAMMirrored 72 GB internal drives

3 pops1qops1, 3


DNS and Domain

DL3852 x 2.2 GHz AMD 2754 GB RAMMirrored 72 GB internal drives

2 pdns1-2 Microsoft Windows 2003

Database: CRM Production and Quality

RP34404 x 1.0 GHz PA8900 CPUs16 GB RAMMirrored 146 GB internal drives2 x PCI Fibre Channel adapter cards

3 cpdb1 cpdb2cqdb1

HPUX Unix11.23

CRM Application DL5858/4 x 2.2 GHz AMD 85012/6 GB RAMMirrored 72 GB internal drives

3 cpapp1-2cqapp1


CRM Web and Operations

DL3852 x 2.2 GHz AMD 2754-6 GB RAMMirrored 72 GB internal drives

4 cpweb1,2cqweb1cops1


OpenView DL3852 x 2.2 GHz AMD 2756 GB RAMMirrored 146 GB internal drives

2 Popenview2,3 MicrosoftWindows2003

Page [34]




OpenView DL5858/4 x 2.2 GHz AMD 8506/1 GB RAMMirrored 2x146 GB internal drives

1 Popenview1 MicrosoftWindows2003

Total 50

6.3.4 Production StorageAll OAKS production utility storage is consolidated into a storage array. This storage supports items such as shared storage for software installations (PeopleSoft, Oracle) clustering files, database files, interface files and attachments for business objects such as Purchase Orders and Resumes.

Item Specification Qty

Power Consumption (KVA)

Heat Output (BTU)

Storage Array EVA 8000 2C6D58 x 146GB 10,000 RPM fibre channel 22 x 300GB 10,000 RPM fibre channel disk drives in ten 14-drive trays for 15TB raw.Expandable to twelve trays in the main rack, plus another 4 trays in the secondary rack, supporting up to 196 drives total. With all 300GB drives, array can scale to 57TB.

EVA 4000 2C2D20 x 146GB 10,000 RPM fibre channel 8 x 300GB 10,000 RPM fibre channel disk drives in two 14-drive trays for 4TB raw.Expandable to four trays in the main rack, supporting up to 56 drives total. With all 300GB drives, array can scale to 16TB. 1

7000 x 1

4000 x 1

8600 x 1

5200 x 1Storage Array configuration server

DL3851 x 2.2 GHz AMD 250 CPU4 GB RAMMirrored 72 GB internal drives 2 750 x 2 2500 x 2

Backup MSL 6060 with 4 x Ultrium 960 tape drives and 60 tape cartridge slots (58 usable – 1 mail slot, 1 cleaning tape

MSL 6030 with 1 x Ultrium 960 tape drive, and 30 tape cartridge slots (28 usable – 1 mail slot, 1 cleaning tape

1 physical3 logical 360 x 2 980 x 2

The storage array is configured in two Redundant Array of Inexpensive Disks (RAID) levels. Each level describes a feature of disk redundancy. By construction, the storage array stripes all storage allocations across the available disks. The following table shows the RAID levels deployed for the OAKS storage arrays at the production.

RAID Level Items StoredRAID 1 FIN, EPM, HCM:

databases file systems

Page [35]


RAID Level Items StoredRAID 5 CRM and ELM:

databases file systems

Database recovery areas (all applications)software file systems (PeopleSoft, Oracle, HP Serviceguard)

6.3.5 Other Production ComponentsThe following table contains the specifications for other miscellaneous hardware components deployed to support production activities:

Item Specification QtyFibre Channel Switches Brocade Storageworks 4/32 2Racks 10240 42U lockable 5Racks A4902 42U lockable 2Patch Panels Panduit 24 port 3Patch Panels Panduit 48 port 3Power Supplies 208 volt 16 amp PDUs 4Power Supplies 208 volt 30 amp PDUs 4Power Supplies 208 volt 60 amp PDUs 4

6.4 Current Network ConfigurationThe network hardware used to manage the OAKS server network is separate and distinct from the general production network hardware used elsewhere in the SOT. The OAKS network hardware connects for basic routing to OIT services and out to OAKS end-users on the Ohio.gov network.

Logically, the production network runs along the same principles as the development network, using a DMZ structure to regulate access to the system. The servers are protected by two logical firewalls:

A firewall protecting external access to the web servers from the Internet and from the PMO administrators

A firewall protecting internal access to the backend servers from both the web servers and the PMO administrators (note: no other access is permitted to the internal servers except via these two methods)

The following diagram shows the relationship of the OAKS networks to its user groups and systems that OAKS communicates with:

Page [36]


The equipment that manages general end-user and administrative IP-based traffic is Cisco however there are two exceptions:

HP Procurve copper switches for HPUX and Oracle clustered high availability IP traffic on a private and isolated network; and

HP-branded Brocade Fibre Channel optical switches for SCSI storage traffic.

The following table contains the specifications for the networking equipment used to manage the OAKS server network at the current production facility. Each of these network components also includes administrative software:

Item Specification Description Quantity

Chassis 6513 13 module Catalyst 6500 chassisChassis to contain, connect, and manage modules (listed below) 2

Supervisor SUP720 Management and monitoring of chassis and modules 2

Router 3825-SECK9Connectivity between OAKS subnets and to outside world 2

Switch WS-X6548-GE-TX 48 port Connectivity within OAKS subnets 8Firewall WS-SVC-FWM-1-K9 Filters traffic into and out of OAKS subnets 4

Load Balancer with SSL Encryption WS-X6066-SLB-S-K9

Encrypts and decrypts end-user traffic and balances incoming requests (http and FTPS) to the OAKS DMZ subnet (demilitarized zone – “front door” to OAKS 2

Intrusion Detection WS-SVC-IDS2-BUN-K9Detects and filters suspicious network traffic, both end-user and administrative 2

Page [37]


Item Specification Description Quantity

Terminal Server 2811-SEC/K9

Provides administrative access to OAKS networking and server resources. Access types include in-band over the main network and out-of-band over POTS (dialup) 2

VPN ASA5540-BUN-K9Provides an encrypted tunnel for administrative traffic 2

Cluster Procurve 2824 Switches the HPUX and Oracle clustering traffic 2Fibre Channel Brocade 4/32 Switches the SCSI storage traffic 2

6.5 PeopleSoft Modules, Versions and Associated Third Party ElementsThe current PeopleSoft environment and its associated software licenses are owned by the State and support/maintenance fees are current with Oracle (formerly PeopleSoft). The State will retain title and ownership of all software elements associated with the Contractor delivering services to the State as they pertain to assets currently owned by the State. The State will maintain all software items currently owned in accordance with previously agreed contracts with the corresponding software providers and wherever possible will work with these software providers to allow the Contractor access to support, maintenance, upgrade, bug-fix and other entitlements currently in place between the software vendor and the State. The following table is a representation of software versions and supporting tools. The version column reflects the current version of application software installed, including PeopleSoft Maintenance Packs and bundles as appropriate. The modules column describes what has been implemented to date.

Product VersionPeopleTools

Version Modules

EPM 8.9 MP4 8.46

Implemented ModulesPlanning and Budgeting

Licensed ModulesCRM Warehouse, EPM Foundation, EPM Portal Pack, Financial Warehouse, HCM Warehouse, Performance Mgmt Warehouse, Planning and Budgeting, Project Portfolio Mgmt, Scorecard, Supplier Rating System, Supply Chain Warehouse, Workforce Profile Mart, Workforce Rewards

FIN 8.8 SP1 MP6 8.46

Implemented ModulesGeneral Ledger, Receivables, Payables, Asset Management, Billing, Purchasing, (Expenses and eSupplier are planned)

Licensed ModulesGeneral Ledger, Receivables, Payables, Asset Management, Project Costing, Contracts, Grants, Cash Management, eSettlements, Financials Portal Pack, Expenses, Resource Management, eSupplier Connection, Supply Chain Portal Pack, Catalog Management, Billing, Purchasing, eProcurement, Strategic Sourcing

Page [38]


Product VersionPeopleTools

Version Modules

HCM 8.9 MP5 8.46

Implemented ModulesHuman Resources, Payroll for North America, Benefits Administration, Time and Labor, ePay, eProfile, eProfile Manager Desktop, eBenefits

Licensed ModulesHuman Resources, Payroll for North America, Benefits Administration, Time and Labor, ePay, Directory Interface, Candidate Gateway, Talent Acquisition Mgr, eProfile, eProfile Manager Desktop, eDevelopment, eBenefits, ePerformance, HRMS Portal Pack

ELM 8.8 8.46 N/A

CRM 8.9 MP1 8.46

Implemented & Licensed ModuleIT Help Desk

Licensed ModulesEmployee Self-Service, Portal Pack

Shared Services Instance (implemented as part of the shared services build)CRM 9.x 8.49

Licensed, To Be Implemented ModulesSupport for Self ServiceCTI IntegrationMulti-Channel InteractionsOnline MarketingInfoSync Server

PeopleTools is installed across the various PeopleSoft server tiers and consists of a range of software components. These components are shown in the following table.

Product Version Purpose

BEA Tuxedo 8.1 RP Transaction processing environment that supports the application server, process scheduler, and the sub-modules in each including report distribution server and event notifications manager.

SQR Reporting and processing language (HCM and Financials)Microfocus Cobol 3.1 and 4.0 Runtime environment for Cobol programs such as Pay Calc and Budget CheckBEA Weblogic 8.1 Java application server that hosts the PeopleSoft servlets:

psc, psp – http web servlets psreports – reporting servlet psigw – integration broker gateway servlet

Java 1.4.2.12 Java runtime environment for Weblogic, and custom integrationsCrystal Reports 9.0 Reporting languagenVision 8.46 Excel like reporting tool used for financial reporting, bundled with PeopleSoft

OAKS does not currently have a version control tool for PeopleSoft online objects. A version control tool must be proposed and provided by the Contractor to ensure overall version integrity for code in all environments provided under the Managed Services Contract.

Page [39]


6.5.1 Software Licensing ConsiderationsOfferors are instructed to consider and address the following considerations with respect to software licensing for Statement(s) of Work contained in this RFP.

1. Where software is existing and licensed by the State as represented herein, the State will continue to retain ownership and maintenance obligations with respect to this software in accordance with existing agreements with 3rd party software vendors (e.g., PeopleSoft, Oracle, existing toolsets);

2. Where software is specified as part of this RFP which does not exist within the State, or is otherwise not available or licensed by the State, is not provided as a included cost in the offeror’s proposal, and will be required for the State to perform these services over the term of the agreement (and if required post agreement), these software elements are to be specified with costs in the Cost Summary and an accompanying software bill of materials (e.g., database licenses, middleware, job schedulers etc) ;

3. Where software is provided as part of this RFP which is in support of the delivery of Managed Services and is not required to be licensed to the State and/or transferred to the State upon conclusion of the agreement, offeror is to provide this software as a priced element as part of their Managed Service offering (e.g., service desk tools, inventory and SL reporting tools, asset tracking etc). Regardless of ownership, the State retains all rights to the underlying State data and reports contained in these software elements;

4. Where software is required as part of the delivery of the Shared Services implementation that requires the State to license this software to support the implementation/development effort (e.g., code versioning, testing, development tools etc), offeror is to specify these software elements with costs in the Cost Summary. Offerors should record the costs in rows 97 or 98 of the Cost Summary and provide a detailed bill of materials that supports the required software costs inclusive of maintenance, updates and upgrades. The State is under no obligation to accept offeror provided pricing, and reserves the right to license this software directly from the OEM software provider at its sole discretion.

5. Where software is required as part of the delivery of the Shared Services implementation that does not require the State to license this software to support the implementation/development effort (e.g., vendor enablers, tools, methodologies and frameworks), offeror is to include these software elements in Cost Summary. Offerors should record the costs in rows 97 or 98 of the Cost Summary and provide a detailed bill of materials that supports the required software costs inclusive of maintenance, updates and upgrades. The State is under no obligation to accept offeror provided pricing, and reserves the right to license this software directly from the OEM software provider at its sole discretion.

RFP Amendment Insertion Page Issued on 11/6/08Insert Between Pages 39 and 40 of Supplement 2

Page [39]A


6.6 PeopleSoft Operations SoftwareThis section describes the PeopleSoft operations software components that are provided with a PeopleTools installation. A PeopleTools installation is included with all PeopleSoft applications. These PeopleSoft operations software products are shown in the following table.

Product Purpose Where Deployed

Process Scheduler

Core scheduling component of PeopleTools that runs and monitors batch processes including Application Engines, Cobol, SQRs, Crystals

Application servers for the PSNT server definition and database servers for the PSUNX server definition

Distribution ServerRegisters and delivers reports. Most OAKS reports are registered into Report Manager As above

Integration BrokerMessaging system that supports near-real time communication between Financials, HCM, and EPM

Gateway on web servers and message processor on application servers

Performance MonitorCollects transaction statistics from the application for service level analysis Monitoring server

6.7 Supporting Application SoftwareThis section describes the installed configuration of the non-PeopleSoft application software that is required to make the OAKS PeopleSoft environments functional. These supporting application software products are shown in the following table:

Product Version Purpose Where Deployed

Micro Focus Net Express 3.1 SP1

Cobol compiler and runtime environment for Windows Server 2003

Application and operations servers for PSNT-invoked COBOLs

Micro Focus Server Express 4.0

Cobol compiler and runtime environment for HP-UX 11.23 PARISC

Database servers for PSUNX-invoked COBOLs

Oracle Database 10g Enterprise Edition 10.2.0.4.0

Database environment with tuning and diagnostics packs Database servers

Microsoft Office 2003PeopleSoft nVision Microsoft Excel plug-ins and Microsoft Word mail merge All Windows servers

Adobe Acrobat 7.0 Reading .pdf formatted documents All windows servers

WinSSHD 4.20 SSH Secure shell for secure Remote accessAll papp, qapp, pfile and qfile servers in the socc domain

IDAutomation 1.0Creates Postal fonts as well as 3of9 bar code fonts for the printing of check warrants

All papp, qapp, pfile and qfile servers in the socc domain

MICR Fonts 1.0Creates the MICR bank font for check printing

All papp, qapp, pfile and qfile servers in the socc domain

6.8 Supporting Operations SoftwareThis section describes the installed configuration of the non-PeopleSoft operations software that is used for OAKS. These supporting operations software products are shown in the following table:


UC4:global 5.0

Batch scheduler product that creates entries in the Process Scheduler request table in order to schedule jobs in PeopleSoft Backup servers

Page [40]



Tumbleweed 4.5

Tumbleweed has 3 components that together enable the support of secure file transfers to/from an agency or a offeror – SecureTransport Edge which resides in the demilitarized zone (DMZ), SecureTransport Server which resides on a backend server inside the firewall, and SecureTransport which resides on the web server in the DMZ or on an agency or offeror workstation or server acting as a file transfer Web and file servers and systems

HP OpenView 8Monitors servers and systems to report and track system health Monitoring and Operations servers

Microsoft Terminal Server 5.2

Store Terminal server CALS for Remote desktop Qops1

WSUS 2.0 Microsoft update deployments Pops1, qops1ISA 6.0 Web Proxy and internal firewall Pops1, Qops1

6.9 Development-Specific Software DeploymentsThis section describes the OAKS software deployment that is specific to the development infrastructure or is different than the production infrastructure software deployment for OAKS. The development-specific software products are shown in the following table:

Product Version Purpose Where DeployedMercury Quality Center 8.2 Functional testing of the OAKS applications Operations serverMercury ITG(currently under evaluation for replacement with QuestSTAT!) 6.0

Change control and migration of OAKS code between environments Operations server

Microsoft Remote Desktop Server Windows 2003

Provides developer access to development environments Terminal servers

Nortel Contivity 4.15

Authenticates and authorizes remote access (i.e. from locations other than the PMO) to the development environments Provided by ATIS

Cognos Reporting 8 Generic reporting tool primarily against EPM Terminal serversCisco VPN 4.8.01.0300 Remote access to OAKS environment OAKS Administrators’ PCs

Note that while Mercury ITG is currently in place for SIR tracking, the Contractor may choose to work with the State to develop an alternative solution.

The State plans to continue to run Cognos from the SOCC. The Contractor will be given access to support and develop Cognos reports from their facility. If the offeror believes that keeping Cognos at a State facility connecting to the EPM database at the Contractor’s hosting site will not be sustainable, the offeror must propose another solution.

Page [41]


This section describes the OAKS software deployment that is specific to the production infrastructure or is different than the development infrastructure software deployment for OAKS. The development-specific software products are shown in the following table:


HP Data Protector 5.5Backup software that manages file system, operating system, and database backups Backup servers

HP Serviceguard 11.17Provides high availability features to the Unix platform Database servers

Cisco Security Agent 4.0Intrusion detection software that monitors traffic to detect suspicious network activity Operations servers

Mercury LoadRunner 8.1Applies online load to the system with the goal of verifying performance under load

Test servers and workstations used for load testing

Symantec AntiVirus Corporate Edition 8.0

Protects servers and all files from harmful computer viruses All Windows servers

HP OpenView 8Monitors servers and systems to report and track system health Monitoring and operations servers

6.10 Administrator Workstation Software DeploymentsThe administrator workstation software components enable the OAKS technical administrators to manage the infrastructure. The default workstation is Microsoft Windows-based. The administrator workstation software components are shown in the following table:

Product Version Purpose

Putty 0.58Secure Shell (SSH) that enables remote login to any server that runs an SSH server; at OAKS this includes all Unix servers

Microsoft Remote Desktop

Windows 2000 and above

Enables remote login to Windows servers, showing the desktop as if the administrator was locally accessing the machine

PeopleTools 8.46

Includes utilities such as: Application Designer – code migrations and object editing Data Mover – data migrations Change Assistant – application of patches and bundles

HP Data Protector Manager 5.5 Configures and manages OAKS backupsMercury ITG 6.0 Testing

Nortel Contivity 4.15Enables connection to the OAKS VPN head, through which direct administrator access to OAKS servers is restricted

6.11 High Availability: Current CapabilitiesThe State requires that Contractor best practices are designed and implemented as part of the quoted service and in keeping with the Service Level Requirements. Offerors are to propose High Availability and fault tolerance solutions that include and leverage to the extent practicable, existing State capabilities. Where the offeror has a preferred alternate approach, and in keeping with the achievement of overall performance, availability and reliability requirements, offerors should propose their recommended solution with a brief description of the solution, capabilities and anticipated improvements to the State High Availability Capability as outlined in this RFP.

Technical Element(s) Current Capability DescriptionWeb and Application Servers PeopleSoft provides its own built-in load distribution between the web and app tiers using a round

robin approach.

Page [42]


Technical Element(s) Current Capability Description Each web server is allocated a list of app servers that it may send requests to. OAKS reorders that list so that each web server’s list starts with the next app server. For example,

web server 1’s list is (app 1, app 2, app 3, and app 4). This means that web 1 will send all its requests to app 1.However, if app1 is not serviceable, after a

timeout, web 1 will then send its requests to app 2, and so on. Web server 2’s list is (app 2, app 3, app 4, and app 1). Using the same approach as above, web 2 sends all of its requests to app 2.If app 2 is down, web 2

will send its requests to app 3, and so on. Although this approach does not provide a “perfect” distribution of load, in practice it works well

and has been simple to maintain.Database Server This helps isolate performance impacts to within an application. The reason for this approach that

differs slightly from the web and application tiers is because those tiers experience small, frequent traffic patterns whereas (particularly during the batch processing window) the database tiers run long-lived and very intensive processes.

Oracle RAC is used for load balancing (active – active failover) for load intensive applications.Storage In addition to hardware (RAID) based solutions, the OAKS database configuration makes use of two key

technologies to provide resilience:

HP Serviceguard – This is a product installed on the Unix servers that host the database software. It provides: The ability to fail over server network cards should they fail; all OAKS database servers have

redundant network cards The ability to failover the database centralized storage from server to server so that the failed

instance can be started on another server

Oracle Real Application Clusters (RAC) – This component clusters physical servers in either an active / standby or active / active configuration such that should an instance e.g. HCPRD fail to provide service on one database server, an instance on another server will assume responsibility for servicing requests. OAKS deploys an active / standby approach. In general, users detect no interruption in service if RAC fails over. Failover is automatic, but OAKS has configured fail back (restoring the services to their original

location) manually in order to improve control over the system.Data Protection / Backup OAKS uses HP Data Protector as the primary backup technology for file systems and databases. The

Data Protector server itself is installed on two servers to provide redundancy, and all storage is configured on the storage array (which is a highly redundant array of disks), and Ultrium tapes.

The backups include several scenarios: Core database backups – HP Data Protector invokes Oracle RMAN to backup the databases to a

special recovery area on the storage array Core files and interfaces – HP Data Protector directly accesses the operating system / file system

on each server to backup the data to disk, and then to tape Server images are copied back to the recovery area on the storage array and then backed up to

tape (OAKS uses HP Ignite to maintain Unix server images, and Data Protector to backup Windows servers)

All backups are first made to the storage array. This enables rapid recovery if the goal is to recover from the most recent backup, which is the most common recovery scenario. The backups are then copied off to tape and the tapes are sent off-site to secure storage.

Network Infrastructure All pieces of hardware on the network (both standalone equipment and modules) are redundant. A failure of any one piece of hardware will not take the network down and will be transparent to users.

High availability is accomplished via three methods: Through the use of load balancing at the application level Through the use of protocols such as Hot Standby Router Protocol (HSRP) at the network layer Through the use of heartbeats at the server level

At the application level, as part of its load-balancing function the Content Switch (CSS) blade on the Cisco Catalyst 6513 switch will detect if a server becomes unavailable, and then will route all traffic to the servers(s) that remain available.

At the network layer, redundant hardware remains in an active/standby configuration where all traffic is routed to the active device. The active and standby devices monitor the status of each other constantly via the HSRP protocol. Once the standby device loses contact with the active one via HSRP it

Page [43]


Technical Element(s) Current Capability Descriptiontakes over as the active device.

PeopleSoft Delivered Capabilities PeopleSoft provides high availability using a combination of automated and manual methods:Automated: PeopleSoft supports multiple web servers delivering the same web site content The web tier relies on a network load balancer to distribute the load from a URL (e.g.

hcm.oaks.ohio.gov) across multiple PeopleSoft web servers Those web servers distribute their requests across multiple application servers; the web servers

support the main content server plus the report manager and the integration gateway components The application servers rely on the selected database software (for OAKS the database is Oracle)

for database-level availability OAKS runs multiple web, app, and database servers for redundancy, availability, and throughputManual: Process Schedulers are defined on several servers, and the administrators fail jobs over to the next

server if the default server is unavailable; the scheduler supports all of the delivered batch processes including Application Engine, Cobol, SQR, Crystals, and nVision reports

OAKS defines multiple Process Schedulers per platform (Windows and Unix)Load Distribution and Balancing The Quality Assurance and Production environments make use of PeopleSoft, Oracle, and Cisco

high availability techniques to improve application uptime. OAKS deploys at least single redundancy for all components (network and server hardware, logical

application services) to avoid single points of failure. In some cases such as the web and application servers, there are high-levels of redundancy which

are a byproduct of the horizontal scaling approach to provide system capacity. This approach adds more servers and services to provide the necessary processing capacity to

support OAKS’ load. A benefit of this approach is that OAKS has much higher levels of redundancy and is therefore able

to absorb more failures before significant end-user impact occurs.Items not specifically addressed in the above

Offeror to propose solution in keeping with achieving Service Levels as outlined in Section 9 – Managed Services SLAs

6.12 Run Book, Operations and Production Scheduling The State maintains an operational “Run Book” to manage the scheduling of respective production operations, jobs and reports (see Supplement Five). In general, these functions are executed on a daily, weekly and monthly basis co-incident with financial and human resources processing and close periods. The Contractor will assume this run book as part of operational responsibilities.

The Run Book will:

Provide a high-level overview of the processes requiring State involvement (e.g., Change Management, Problem Management);

Outline the now current operating schedule for major production and operational schedules which include jobs, processing, report generation, interfaces and other regularly scheduled and routine tasks associated with the offeror performing services in this area;

Be used by the Contractor to provide the Services; Identify the process interfaces; and Describe how the State and the Contractor will interact during the Term.

Until such time as the State and the Contractor complete and approve the Run Book, the Contractor will use the State current processes and procedures existing as of, and delivered to the Contractor prior to, the Effective Date to the extent that such processes and procedures are applicable to the new operating environment. In the event that the State does not have existing processes and procedures as of the Effective Date or such processes and procedures do not apply to the new operating environment, the

Page [44]


Contractor will document the processes and procedures for the State environment existing prior to the Effective Date as required by the Contractor to perform the Services. The final Run Book will supersede all prior processes and procedures unless otherwise specified.

The Contractor must:

Assign an individual to be the single point of contact to the State for the Run Book development and maintenance;

Provide the proposed table of contents and format for the Run Book for the State review and approval;

Develop and provide the draft Run Book, which will be customized by the Contractor to reflect the process interfaces between the State and Contractor;

Review the State feedback and revise the draft Run Book to incorporate mutually agreed changes;

Upon request, communicate the Contractor’s rationale for not including specific State comments or changes in the Run Book;

Provide the final version of the Run Book to the State for its acceptance and approval, which will not be unreasonably withheld;

Conduct process maturity assessments, identify process inhibitors, and propose process improvements to the State, as required;

Jointly review the Run Book on an annual basis or more frequently, as required, and update and maintain the Run Book accordingly; and

Provide appropriate Contractor employees with access to the Run Book, as required.

The State will:

Assign an individual to be the single point of contact for the Run Book development and maintenance;

Review and approve the proposed table of contents and format for the Run Book; Review and provide documentation containing the State’s comments, questions and proposed

changes to the draft Run Book; Request the Contractor’s rationale for not including specific State comments or changes in the

Run Book, as appropriate; Acknowledge receipt of the final version of the Run Book and provide acceptance and approval,

which will not be unreasonably withheld; Identify process inhibitors and propose process improvements to the Contractor, as

appropriate; Jointly review the Run Book on an annual basis or more frequently, as required; and, Provide appropriate State employees with access to the Run Book, as required.

Note: important service level considerations regarding the current production schedule are included in Section 9.

Page [45]


6.12.1 Data Archive and Purge ConsiderationsBased on experience running the PeopleSoft environments since the implementation of OAKS, the State has determined that there may be a requirement for accommodating the archive and purge of historical or obsolete data from the production environments. At a high level, the rationale for implementing archive and purge functionality is to ensure that: the overall performance characteristics of the system is not compromised processing or accommodating historical data; the overall costs associated with storage, backup and maintenance of historical data are cost effective; and requirements for creating subsets of data to support the development, testing and training of projects such as the Shared Services implementation addressed in this RFP in Section 10.

Based on the high level requirements outlined above, the State has evaluated various methods to accomplish the archive and purge functionality including: the development of customized scripts to facilitate the extraction and migration of data to online, offline or purge data stores; and the purchase and subsequent implementation of commercial packages available on the marketplace from vendors such as IBM, HP and Applimation. Based on the review of the available packages and a custom set of scripts, the State is contemplating the development of custom scripts to achieve the archive and purge requirements but due to the timing of this RFP, and the probability that offerors may have pre-existing tools, techniques or methods, the State requests that offerors propose their preferred method for managing general archive and purge requirements in their PeopleSoft managed services environments. Offerors are required to include a high level description of capabilities, features, configuration and limitations of their provided toolset, any underlying assumptions as to the basis for provision of these functions, and any incremental pricing associated with the delivery and implementation of these capabilities.

Offerors are to note that these functions are not required if, in the view of the offeror: 1) overall Service Levels can be achieved, particularly those pertinent to application performance; 2) storage costs are not significant as to warrant the provision of these functions in consideration of cost to deploy and manage these functions relative to the cost of the underlying storage; and 3) the data sub-setting requirements of the Shared Services project and other similar projects that may arise in the future can be achieved.

6.12.2 Data Masking and Information Privacy in Non Production Environments

The State has a requirement for all non-production environments (e.g., development, testing, training) that require production data refresh from time to time as outlined in the table in Section 6.1. Elements of production data that require protection under information privacy regulations such as Social Security numbers, bank account information and other sensitive data must be protected in these environments. As a result of these requirements, and as highlighted by certain elements of the Shared Services implementation, the State has conducted a preliminary analysis and several vendor driven proof-of-concepts and demonstrations as part of the formulating a strategy to achieve these requirements including a preliminary review of the available packages from Applimation and IBM, features available in Oracle DBMS 10G.


Page [45]A


Due to the timing of this RFP, and the probability that offerors may have pre-existing tools, techniques or methods, the State requests that offerors propose their preferred method for achieving data masking or private data in their PeopleSoft managed services environments. The State has no plans or preferences with respect to selecting or implementing a package or data masking technique prior to the award of a Managed Services contract. Offerors are required to include a high level description of capabilities, features, configuration and limitations of their provided toolset or approach, any underlying assumptions as to the basis for provision of these functions, and any incremental pricing associated with the delivery and implementation of these capabilities.


Page [45]B


6.13 PeopleSoft Implemented Modifications

6.13.1 Finance ModificationsThe following table depicts the modifications to the implemented FIN system and provides an indication as to the number of hours required to implement the customization. Offerors are encouraged to use this guide to better understand the State modifications and use these to assist in factoring support and upgrade considerations.

Module Description of the Mod Hours of Effort

AP 1099 Extract 174AP 1099S missing fields 106GL Account Number 35BD Activate Inactive Dimension 38GL Actuals Ledger Extract 227PO Add Controlling Board and Release and Permit Fields to Requisition and Change Request

Approval Pages40

BD Add line Item Page Required Chartfileds 70AR Aged receivable balances by any level of data 46GL Agency Cash Balance Report 157AP Aging of unpaid invoices 213GL Allocation Calc Log Query 46PO Allow item price change on requisition 35PO Allow Multiple Open Item Contracts 49AM AM Integration Queries 115AM AM Report for CAFR Preparation (Note 8) 203PO Amount Only Blanket Purchase Order 82AP AP Workflow Approval Menu Customization 372GL Appropriation Report and Track Adjustments By Type (Executive Reduction, Legislative

Adj., etc.)264

PO Approver Changes Re-Trigger Workflow 353AM Asset Fields for Buildings 113AM Asset List Report 243BD Attach Budget Documents 162AP Auto void for Stale Date 984PO Automatic Item De-Activation 150AM Available Assets Query 46BI Billing Interface 90PO Blanket Approvals 387BD Budget Journal Extract 246GL Budget Ledger Extract 227BD Budget Reports Extract (Blue Book) 171GL Budget Spreadsheet Upload 189BD Budget Upload 353PO Capture Contract Bill Type 39PO Capture Contract MBE Flag 75GL Capture Grant Lifetime Attributes 93AR Cash Timing Reconciliation Report 375AM Catastrophic Insurance Query 106AP CCD+ 121AR Certified Item to AG Office Query 59AP Change CTX Data Elements for P-Card Vendor Payments 111PO Change Order Workflow 137BD Chartfield Mapping 588AP Chase EFT Rejects is not rejected correct transactions 54

Page [46]



GL Commitment control amount type default 36AM Condition Code Field 75PO Contract Expenditure/Encumbrance Reporting 59AP Contract ID for Threshold / MBE Reporting 186PO Controlling Board 752GL Copy of Master Tables 150AR Create Customer Types 20AP CTX 354AP Custom MICR 96AP Custom Travel Expense Integration 158AP Custom Travel Expense Report Page 668AP Custom Travel Expense Setup Pages 525GL Daily Cash Balance by Agency by Fund - RTRBL07A 195GL Daily Fund Cash Statement 228AR Daily Revenue Report (Taxation) - Query 59PO DAS Release and Permit 670BD Dimension1 Page 39AR Display Lockbox ID on Deposit Entry Search Page 38AM Disposal Code Translate Value 1PO eControlling Board Waivers 175AP EDI Agent Modifications 354AP EDI Invoices 443AP EFT File Printed Remittance 304AP EFT Reject File from Bank 134AR Electronic Revenue (MAF/ACH) Processing Updates 180AR Electronic Revenue Process Journal-BAI 519AR Electronic Revenue Process Journal-MAF 519BD Executive Agency Budget Request-Detail 229BD Executive Agency Budget Request-Summary 229GL Expenditure by Fund by ALI by Account 226AP Expenditure report 46GL Extract GL Journals for Agencies 197GL Federal Attachment A 180TC FIN Report Bursting 227TC FIN run control process 150BD Fund Activity Summary Report 365BD Fund Balance Calculation Report 229PO FYE ChartField Update 208GL GRF Disbursement and Transfers Out Report 195AR Holding accounts and open items 46BD Import Budgeting Data Delivered Interface 99BI Inbound Customer Interface 845PO Inbound Encumbering Documents Interface 576AP Inbound Voucher Interface 594BD Income Sources Report 229AR Inter-Agency Billing 240AR ISTV Process 663GL ISTV Receivable Invoice 113PO Item Restriction 282AP JFS Automated Warrant Cancellation 437GL Journal Adjustments Processed Report 48BD Legislative Services Committee 354GL Lifetime expenditure and revenue, RGRNT11A/12A 685AR Lock Box Interface 227PO Mass Cancelation of PO at FYE 70BD Model Status update Process 101

Page [47]



AP Modify delivered check format for OAKS warrant 153AP Modify Recon for 7 digit check # 6BI Modify Revenue Recognition Basis 35BI Modify Review (Adjust) Line History 20PO Modifying PO distribution lines and Special Approvals/Thresholds 96GL Monthly Expenditure Budget Variance Report 150GL Monthly Revenue Budget Variance Report 106PO Multiple Billing Locations 181BI Net Adjustment Amount Query 29AP ODOT P-Card Interface 394AP ODOT P-Card Interface (Outbound) 245PO OIT Release and Permit 1143PO Online-Encumbrance Balance by Fund - RSPND04 330PO Outbound Encumbering Documents Interface 227AP Outbound Payment Data Interface 277PO Outbound Spending Items Interface 576AP Outbound Vendor Interface 277AP Out-of-State travel query 46AR Payment Loader 121GL Payroll Jrnl Gen by Agency 119AP P-Card voucher origin 54AR Pending item 192AP Postal Bar Code 231AP Pre-Note Waiting Period 17GL Prevent Back-Dating of transactions to ensure proper cash balance 158GL Project/Grants Reports - RGRNT03S-05 200PO Purchasing Contracts in Sourcing Process 121PO Purchasing History By Product Reporting 90AP Purchasing Validations on Vouchers before Voucher Build 473GL Query All Journals by Agency by Day 29GL Query All Journals by SAC 29PO Re-Design Printed PO 111BD Relabel Field Names 75GL Report of Cash Receipts and Disbursements for Government and Proprietary Funds 228GL Report of GRF Cash Activity 219AM Reports for DAS Certification 1 602AP Return to Agency Paycycle 264AP Return to Agency Warrants Sign Out Sheet 29GL Revenue Report RRVSM02S/RRVSM03S 79AP Securing Payee Name on Single Payment Voucher 105BD Six-Year Summary Report 415BD Six-Year Summary Report - Legislature 415PO Special Approvals for Interfaced POs 110BI Standard and Consolidated Invoice Format 510GL Summarized Revenue by Fund by Month Report-RRVSM09A 195GL Summary of Expenditures by Fund, Object Report - RSPND22S 195GL Summary Trial Balance by Fund 255AP Taxable and non taxable payments Query 46PO Thresholds 990AP TOS Interface for Payment Reconciliation 174AR TOS/AGENCY Deposit Review 416AP Totals by vendor by commodity/service category 106GL Update Split Payroll Journal Application Engine 242BD Variance Analysis Report - Multi-Version Summary 415BD Variance Analysis Report-Detail 415PO Vendor address on requisition 68

Page [48]



PO Vendor Term Contracts 227AP Vendor Type 6AP View vouchers exceeding threshold on voucher page 57AP Voucher Date 86AP Voucher Link to Image 121AP Voucher Payment Security Page 49AP Voucher workflow based on object code/agency 435AP Warrant Interface File 599GL Year to Date Daily Cash Statement - RTRBL04S 145

6.13.2 HCM ModificationsThe following table depicts the modifications to the implemented HCM system and provides an indication as to the number of hours required to implement the customization. Offerors are encouraged to use this guide to better understand the State modifications and use these to assist in factoring support and upgrade considerations.

Module Modification Description Implementation Hours

PY Per run control record (200x1hr ea.) 715PY 182 Day Rules Processing 330PY Ability for Agencies to create combination code real-time and to limit the use of combo codes based on

agency structure322

PY Ability for system to payoff leave balances as a percentage of base pay based on separation code and years of service.

273

PY Ability for the system to automatically create arrears and split checks. 519PY Ability for the system to bill selected vendors for deductions during reversal process. (PERS, Def. Comp.

etc).46

PY Ability for the system to generate a specific garnishment register 330PY Ability for the system to maintain audit trail/history on all the Maintain Payroll data pages: Who made

the changes, audit all fields (tax and deductions), and configuration values.310

PY Ability for the system to prevent changes made to retirement service credit deduction once it has been setup (based on security - only DAS can change)

96

PY Ability for the system to provide online access to payroll information grouped by Agencies during and after Payroll process has run.

38

PY Ability to generate city and/or county non-compliance reports 707PY Ability to limit the agency's ability to post exempt tax status or over 9 exemptions. 35HR Ability to prevent a position and/or employee from being assigned, except by DAS, a rate outside of

the minimum & maximum established at the job code level17

PY Ability to provide YTD totals for all deductions by pay period by agencies. 605PY Ability for the system to load EFT errors from banks to an error worklist. 314HR Accounts Receivable for Vendor Payment - Modify SQR (BEN042) 424TL Auto Assign Workgroups 597BN Benefit Deductions Owed Report 838BN Billing Statements 124BN Calculate eligibility for Part-time employees 451HR Calculate service and frozen service - SQR 551HR Certification Interface 227HR Changes to PS_JOB 842PY Chartfield Mapping (Fund, AGY, ALI, Account) 272PY Check-Off Charges 979HR Claim Details - Ability to track multiple appeal decisions from a variety of committees, boards and

decision authorities. 62

BN COBRA 90-Day Termination - Ability to generate COBRA Termination Notice that is sent to participants 270

Page [49]



90-days prior to loosing coverage. BN COBRA Billing Statement 203BN COBRA First Notice 213BN COBRA Qualifying and Secondary Notification letters 222TL Combo Code Access Restriction 298BN Communication / Comments Fields. The system will support comment fields to enable the tracking of

communication between the State and the employee. 75

TL Comptime Payout or Deletion 597HR CR29 Leave Accrual Change 460BN December Conversion 496TL Display Schedule On Timesheet Page 298HR EHOC Page and Update Process 549BN Enrollment Statistics - Ability to generate enrollment statistics following the State’s open enrollment

event195

HR Felony Data. Ability to track people who cannot be hired (e.g., convicted felons) - statutory requirement and limit view access to this data.

159

PY Final Check - No Direct Deposit Process - 1 150BN FMLA Eligibility based on last 12 weeks worked should update Standard Hours 592BN FMLA Notification - Notify employee following the approval of a FMLA leave, and include the details of

the certification in the notification. 195

BN FMLA Status Report should include hours in addition to weeks and show each certification (or FMLA request or FMLA ID) for the employee and the hours and weeks associated with each request.

60

BN General Deduction Overrides 597BN Generate report to identify employees and dependents with State duplication of coverage. 111TL Hours Outside Pay Period 29HR HR Config Changes 880HR HR Custom Agency Changes 182BN Inbound BN Interface 454HR Inbound HR Interface 227BN Inbound interface to load dependent validation from vendors. 221PY Inbound Payroll Interface 1784TL Inbound TL Interface 520PY Job & Family 519PY Leave Accrual 519BN Leave Accrual. Ability to prorate leave accrual, apply payroll maximum and distribute leave accrual

quarterly514

BN Load FMLA Hours taken into the FMLA Module in order to calculate FMLA eligible. 514HR Mass Hire. Ability to mass hire or rehire employees for certain events such as State Fair, Tax Season,

etc.245

HR Medicare B Notification 227BN Modify Confirmation Statement 261BN Modify Enrollment Statement 60HR Modify the delivered EEO-1 (PER017) report and list all job codes, actions and disciplinary actions. 111PY Need ability to generate letters after confirmation process going to court, employees, CSPC, etc.

Indicating balances, deduction amount, other garnishments, salary and other items. These letters are currently automated.

335

HR Next Step Increase Date 597HR Org Views. Ability to create graphical organizational views (modify Organization Report POS006 to add

fields).60

BN Outbound BN Interface 5325HR Outbound HR Interface 1361PY Outbound Payroll Interface 2741PY Pay Group ID update 529HR Position Approval. Ability to approve position, validate funding, ceiling prior to hiring employee into

Position. 19

HR Position Data. State requires several fields to be tracked on Position Data. 180HR Probation Processing 597HR Projected Probationary & Performance Evaluation - New Run Control Menu 516

Page [50]



HR Roll-over changes made to Salary Plan, Grade or Step to appropriate Positions (similar to update by Job Code process).

124

HR Secure Address Data. State needs to prevent address data from being viewed online for certain employees.

155

HR Service Credits. Ability to calculate seniority, institutional and retention credits. 689PY STRS Annual Interface 519PY Temporary CF interface (spreadsheet upload - can manual enter CAS/HCM?) 545PY Temporary Employee Payment (expense and fringe) Interface HCM>CAS 601PY Temporary HCM vendor interface (CAS/AOS>HCM) 601PY Temporary HCM vendor payment Interface HCM>CAS 601HR Test Result Data. The State needs to track drug test results, prevent hire if results are acceptable and

reports to manage the overall process.667

PY The ability for the system to automatically deduct fair share dues if after 60 days the employee does not join the union. - Religious objector/R01-D01

946

PY The system will support a pre-notification process that will validate the employee's name, SSN, and account number with banking institutions.

29

PY The system will support client designated payroll check and client designated control numbers. 1246PY The system will support supplementary pays based on service (e.g., longevity). 639PY The system will support the generation of a payroll journal report detailing employee earnings,

deductions and time balances by account. Includes year-to-date totals.111

TL Time and Labor Queries 166TL Time and Labor Rules 17903HR Union Membership - Modify SQR (PER009) 250PY United Behavioral Health 519BN Vendor Reconciliation 243BN View Leave Balances - Ability to view leave balances for employee on one page 108

Total HCM Modifications 61,953

6.14 Current ReportsA listing of current reports from PeopleSoft has been included as Supplement Four.

6.15 Data Transfer ProgramsThe State uses Ascential DataStage ETL and Oracle Materialized to transfer data from the transactional systems to the EPM Data Warehouse.

6.16 Key Interfaces by SystemThe following table reflects a recent snapshot of HCM, EPM and FIN interfaces supported by OAKS. Tumbleweed, as referenced in Section 6– Current Technical Environment Overview, is a key component to OAKS interface architecture.

No interfaces other than PeopleSoft application messaging exist for the other applications.

HCMInterface Name Interface DescriptionDDP001 Direct Deposit Transmittal file OH_DDP001_FTP Payroll Files to Huntington Bank OH_DDP001_FTP_DELAYED Payroll Files to Huntington Bank - Sent 20 minutes after first file is sentOH_DDP001_FTP_MTHLY Payroll Files to Huntington Bank OH_DDP001_FTP_MTHLY_DELAYED Payroll Files to Huntington Bank - Sent 20 minutes after first file is sentOH_HR35 Employee Certification (CERT) Interface

Page [51]


HCMInterface Name Interface DescriptionOH_IMPORT Used for downloading files for SPRT toolOH_INH01 INH01 Inbound Interface Load to Additional Pay Tables OH_INH02 EPDP eligibility outbound interfaceOH_INH03B Standard General Deduction Inbound Interface OH_INH04 This is an outbound interface that sends employee general deductions withheld for various insurance

credit unions and loan payments not related to a Benefit plan. OH_INH04A Updated version of INH04 - Standard Deduction OutboundOH_INH05 Employee Master OH_INH06 Object Of Expense Outbound InterfaceOH_INH07 Position Control Outbound Interface OH_INH08 TCD Inbound InterfaceOH_INH12 United Way Eligibility - Annual Combined Charitable Campaign - Outbound OH_INH15 Bi-Weekly City Tax for MunicipalitiesOH_INH19 Outbound Interface that sends Health Benefit Information NOT paid to Payroll Deductions to vendorsOH_INH20A Benefits Trust Outbound interfaceOH_INH20B COLE VISIONOH_INH20C Vision planOH_INH20D REGULAR HEALTH INTERFACE OH_INH20E Delta Dental Outbound InterfaceOH_INH20G United Behavioral Health Outbound InterfaceOH_INH22 UET Computer Purchase PlanOH_INH24 WageWorks Eligibility Outbound InterfaceOH_INH246 Ohio Department Budget LoadOH_INH25 FSA Eligibility Outbound InterfaceOH_INH27B Deferred Compensation Separations File OH_INH28 HIPAA EDI 834 fileOH_INH29A Inbound interface for drug test resultsOH_INH30A This is an outbound interface which generates a file containing PERS/LERS information all of which is to

be distributed to OPERS only.OH_INH30B Service Buy Back OutboundOH_INH30C STRS BiWeekly Outbound Interface OH_INH30D HERS Outbound InterfaceOH_INH30F STRS ANNUAL INTERFACEOH_INH322 Account Code LoadOH_INH40 Outbound Leave Accruals Interface OH_INH41 State Phone ListOH_INH50 This is an outbound interface for the OIT directory consolidation project OH_INTF This Interface def is used for testingOH_KRONOS Kronos Crosswalk Interface OH_PY32 Load EFT Errors from BankOH_SWEEP_DOT_RECONCILIATION_FILES

Sweeps only DOT Files out of the Reconciliation Directory.

OH_SWEEP_RECONCILIATION_FILES_TO_STAGING

Sweeps all files that need to be reconciled to the proper staging directories.

OH_SWEEP_RECONCILIATION_FILES_TO_STAGING_05_07


OH_SWEEP_RECONCILIATION_FILES_TO_STAGING_07_MTHLY


OH_TINF01 This is an Inbound Interface file for Chartfield MappingOH_TINF02 Employee Payment Expense and Fringe Outbound Interface OH_TINF03 HCM Vendor paymentOH_TINF05 Vendor data file to ROSCOE PAY015A Warrant ReconciliationPAY016B Savings Bond Federal Reserve

Page [52]


HCMInterface Name Interface DescriptionAR25001 FIN2025 Outbound EFT Pay cyclesFIN2025_FTP_UPLOAD_CHASE UploadFIN2025_FTP_UPLOAD_KEYBKFN2025_FTP_UPLOAD_KEY OHPO027 OHPO027OH_AP052 Redeemed warrant file from TOSOH_AP052_OUT Output of OH_AP_7DIGIT programOH_AP053OH_AP055 EFT Rejects OH_AP072 OH_AP072OH_ECIN0001 INF02 File Load Via ECIN0001 OH_ECIN2001 INF02 File Loading via ECIN2001OH_ECINJFS06OH_ECINJFS2OH_ECINJFS3 OH_ECINJFS4OH_ECINJFS6OH_ECINJFS7OH_ECINTAX2OH_EX002 Travel Expense Integration InterfaceOH_INF01 Outbound Vendor data interfaceOH_INF02 Single Payment vendors InterfaceOH_INF03 Outbound Payment Data InterfaceOH_INF04 Inbound EDI Interface OH_INF04_EDI_OUT OH_INF04_EDI_OUTOH_INF09AOH_INF09A_MAF Inbound MAF ProcessingOH_INF09B Inbound ACH Processing OH_INF09B_ACH Inbound ACH ProcessingOH_INF15 Master Table InterfaceOH_INF17 Inbound Encumbering InterfaceOH_INF18 Outbound PO Interface OH_INF22 Inbound Vendor Contract InterfaceOH_INF23 ECB Waivers Inbound Interface OH_INF25 Outbound Spending Items Interface OH_INF28 Inbound Pending Item InterfaceOH_INF29 ODOT P-Card Inbound Interface OH_INF30 Inbound Billing InterfaceOH_INF31 Customer Load OH_INF32 P-Card Outbound InterfaceOH_INF33 Print Warrant File InterfaceOH_INF34 OH_INF34OH_INF34_AE This Inbound interface loads payments to be cancelled in OAKS. OH_INF35OH_INF41 Inbound Budget Journal Flat File Import OH_INF42 Inbound GL Journal InterfaceOH_INF43 Outbound Speedchart Interface OH_INF44 Inbound Speedchart InterfaceOH_INF45 Outbound Ledger GL InterfaceOH_INF46 Outbound Budget Journal Interface OH_INF49 Inbound OIT Release and Permit

Page [53]


EPM (Planning and Budgeting)Interface Name Interface DescriptionINF41 Journal Extract

FINANCIALSInterface Name Interface DescriptionAR25001 FIN2025 Outbound EFT Pay cyclesFIN2025_FTP_UPLOAD_CHASE UploadFIN2025_FTP_UPLOAD_KEYBKFN2025_FTP_UPLOAD_KEY OHPO027 OHPO027OH_AP052 Redeemed warrant file from TOSOH_AP052_OUT Output of OH_AP_7DIGIT programOH_AP053OH_AP055 EFT Rejects OH_AP072 OH_AP072OH_ECIN0001 INF02 File Load Via ECIN0001 OH_ECIN2001 INF02 File Loading via ECIN2001OH_ECINJFS06OH_ECINJFS2OH_ECINJFS3 OH_ECINJFS4OH_ECINJFS6OH_ECINJFS7OH_ECINTAX2OH_EX002 Travel Expense Integration InterfaceOH_INF01 Outbound Vendor data interfaceOH_INF02 Single Payment vendors InterfaceOH_INF03 Outbound Payment Data InterfaceOH_INF04 Inbound EDI Interface OH_INF04_EDI_OUT OH_INF04_EDI_OUTOH_INF09AOH_INF09A_MAF Inbound MAF ProcessingOH_INF09B Inbound ACH Processing OH_INF09B_ACH Inbound ACH ProcessingOH_INF15 Master Table InterfaceOH_INF17 Inbound Encumbering InterfaceOH_INF18 Outbound PO Interface OH_INF22 Inbound Vendor Contract InterfaceOH_INF23 ECB Waivers Inbound Interface OH_INF25 Outbound Spending Items Interface OH_INF28 Inbound Pending Item InterfaceOH_INF29 ODOT P-Card Inbound Interface OH_INF30 Inbound Billing InterfaceOH_INF31 Customer Load OH_INF32 P-Card Outbound InterfaceOH_INF33 Print Warrant File InterfaceOH_INF34 OH_INF34OH_INF34_AE This Inbound interface loads payments to be cancelled in OAKS. OH_INF35OH_INF41 Inbound Budget Journal Flat File Import OH_INF42 Inbound GL Journal Interface

Page [54]


OH_INF43 Outbound Speedchart Interface OH_INF44 Inbound Speedchart InterfaceOH_INF45 Outbound Ledger GL InterfaceOH_INF46 Outbound Budget Journal Interface OH_INF49 Inbound OIT Release and Permit

Page [55]


7 Overall Program Governance Requirements

7.1 Contractor Account RepresentativeDuring the Scope of Work Term, the Contractor will designate an individual who will be primarily dedicated to the State account who (i) will be the primary contact for the State in dealing with the Contractor under the Statement(s) of Work contained herein or in effect, (ii) will have overall responsibility for managing and coordinating the delivery of the Services, (iii) will meet regularly with the State Account Representative and (iv) will have the authority to make decisions with respect to actions to be taken by the Contractor in the ordinary course of day-to-day management of the Contractor’s account in accordance with this Scope of Work (the “Contractor Account Representative”).

7.2 State Account RepresentativeDuring the Scope of Work Term, the State will designate a senior level individual and suitable alternates to perform this role in the event of vacation or absence who (i) will be the primary contact for the Contractor in dealing with the State under this Scope of Work, (ii) will have overall responsibility for managing and coordinating the receipt of the Services, (iii) will meet regularly with the Contractor Account Representative and (iv) will have the authority to make decisions with respect to actions to be taken by the State in the ordinary course of day-to-day management of this Scope of Work (the “State Account Representative”).

7.3 Establishment of Service Management Steering and Oversight CommitteeThe Contractor and the State will appoint a Service Management Steering Committee (the “Service Management Steering and Oversight Committee”), made up of a number of key executives from each Party (inclusive of the Contractor Account Representative and the State Account Representative), which will meet at a minimum on a quarterly basis, and at such time as its members or the Parties deem appropriate to (i) review and analyze the monthly performance reports for the preceding period, including any actual or anticipated budget or schedule overruns, service level attainment of targets, any issues or outages that result in the creation of a service credit and the Parties’ overall performance under this Scope of Work, (ii) review progress on the resolution of issues, (iii) provide a strategic outlook for the State requirements,(iv) review any Change Order or SOW outside of the scope of services described in this RFP, and (v) attempt to resolve, or designate individuals to attempt to resolve, any disputes or disagreements under this Scope of Work. Although the State Account Representative and the Contractor Account Representative will remain as members of the Service Management Steering Committee, either Party may change its other representatives from time to time upon written notice to the other. In addition, the Parties may mutually agree to increase or decrease the size, purpose or composition of the Service Management Steering Committee in an effort for the Contractor to better provide, and for the State to better utilize, the Services. All actions of the Service Management Steering Committee required under this Scope of Work will require the mutual consent of the Parties.

Page [56]


7.4 Establishment of a Managed Services Oversight CouncilThe Contractor and the State will assemble a Managed Services Oversight Council which will be chaired by the State Executive Program Manager and will meet monthly to address business requirements, technology alignment, Contract performance, Performance Standards, continuous improvement, benchmarking, quality assurance and escalated issues and disputes. The Contractor Account Representative will serve as the Contractor’s highest ranking representative on such committee and have the authority to commit the Contractor (subject to State approvals) to implement the course of action as deemed necessary by the State Executive Program Manager.

During the Term, representatives of the Parties will meet periodically to discuss matters arising under this Scope of Work. Such meetings will include the following:

The meetings by the committees noted above. Such other meetings of the State and the Contractor personnel, including senior management of

the Contractor, as the State may reasonably request. For each such meeting, upon the State request, the Contractor will prepare and distribute an

agenda, which will incorporate the topics designated by the State. The Contractor will distribute such agenda in advance of each meeting so that the meeting participants may prepare for the meeting. In addition, upon the State request, the Contractor will record and promptly distribute minutes for every meeting for review and approval by the State.

The Contractor will notify the State Executive Program Manager in advance of scheduled meetings with end users or designated alternates (other than meetings pertaining to the provision of specific Services on a day-to-day basis) and will invite the Executive Program Manager to attend such meetings or to designate a representative to do so.

7.5 Key PersonnelIn an effort to develop an environment in which the Services may be provided in an effective manner, the Parties may jointly designate from time to time certain key Contractor management positions, including the Contractor Account Representative (“Key Personnel”).“Key Personnel” will include the following:

Contractor Account Representative Managed Services Delivery Team

o PMO Leado FIN Leado HCM Leado Infrastructure Leado Data Warehouse Lead

Shared Services Delivery and Implementation Teamo PMO Leado Technical/Finance Leado Training Lead

Page [57]


o OSSC Readiness and Change Lead

7.6 Regular Meetings and Conference CallsWithin thirty (30) days after the Effective Date, the Parties will determine an appropriate set of scheduled periodic monthly meetings or telephone conference calls to be held between representatives of the State and the Contractor. At either Party’s request, the other Party will publish its proposed agenda for any meeting sufficiently in advance of the meeting to allow meeting participants an opportunity to prepare. All meetings will be held in such location as mutually agreed by the Parties. The Parties contemplate that such meetings will include the following:

A monthly meeting among the State Account Representative, the Contractor Account Representative and any other appropriate operational personnel to discuss daily performance and planned or anticipated activities that may adversely affect performance or any contract changes;

A quarterly management meeting of the Service Management Steering Committee; and An annual senior management meeting to review relevant performance and other issues.

7.7 System ChangesContractor will comply with the following control procedures for any changes to the in-scope environments or supporting production infrastructure (“System Environment Changes”):

Contractor will schedule its implementation of System Environment Changes so as not to unreasonably interrupt State business operations.

Contractor will make no System Environment Changes that would materially alter the functionality of the systems used to provide the Services or materially degrade the performance of the Services, without first obtaining State approval. In the case of an emergency, and in keeping with State security policies in effect, the Contractor may make temporary System Environment Changes at any time and without State approval, to the extent such System Changes are necessary, in the Contractor’s judgment, (i) to maintain the continuity of the Services, (ii) to correct an event or occurrence that would substantially prevent, hinder or delay the operation of State critical business functions; and (iii) to prevent damage to the Contractor’s network. The Contractor will promptly notify the State of all such temporary System Environment Changes. At the conclusion of the emergency the Contractor will restore any System Environment Changes to the pre-emergency state, and if the change is deemed necessary for normal operation of the system, a corresponding change request will be initiated for State review and approval.

The Contractor will review, and perform a root-cause analysis of any deviation from scheduled System Environment Changes and failed System Environment Changes.

Prior to using any software or equipment to provide the Services, Contractor will utilize customary testing efforts to verify that the item has been properly installed, is operating substantially in conformance to its specifications, and is performing its intended functions in a reliable manner in keeping with the defined Service Levels in effect at the time of the change.

Page [58]


Contractor will follow a mutually agreed, formalized and published methodology in migrating systems, environments, configurations and Contractor supplied programs from development and testing environments into production environments.

7.8 Extraordinary EventsIf an Extraordinary Event occurs, the Parties will promptly meet to discuss and review the potential impact, including the impact on Contractor’s charges and resources (including base charges and rates as appropriate). The Parties will work to agree on equitable adjustments, if required, to then-current resources, service levels, and pricing. If the Parties are unable to reach a mutual agreement on such equitable adjustments, the Parties will follow the internal escalation procedures. As part of a mutually agreed upon resolution to any Extraordinary Events, the Parties may agree: (i) to add to, or eliminate from, the provision of Services, certain Contractor Personnel providing the Services, as the case may be); or, (ii) to modify as appropriate the costs (including appropriate indirect and overhead costs) as part of any targeted resource additions or targeted resource reductions. Any such changes to the Services will be documented in a mutually agreed upon Change Order. In the event the Parties so agree, Contractor will promptly enact the targeted resource additions or targeted resource reductions, but in no event will such targeted resource additions or targeted resource reductions take more than three (3) months from the effective date of any related Change Order.

7.9 Dispute Resolution

7.9.1 Informal 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 Managed Services Oversight Council 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 Managed Services Oversight Council, each Party will prepare and submit to the Managed Services Oversight Council a detailed summary of the dispute, the underlying facts and their respective positions, together with any supporting documentation.

The Managed Services Oversight Council will address the dispute at its next regularly scheduled meeting or, at the request of either Party, will conduct a special meeting within ten (10) Business Days to address such dispute. The Managed Services Oversight Council 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 Team. If the Managed Services Oversight Council is unable to resolve a dispute within thirty (30) days of the first Managed Services Oversight Council meeting addressing such dispute (or such

Page [59]


longer period of time as the Parties may agree upon), either Party may refer the dispute to the Managed Services Oversight Council 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 Managed Services Oversight Council, the State Project Director and Contractor Account Executive will each prepare and submit to the Managed Services Oversight Council a detailed summary of the dispute, the underlying facts and their respective positions, together with any supporting documentation.

The Managed Services Oversight Council will address the dispute at its next regularly scheduled meeting or, at the request of either Party, will conduct a special meeting within twenty (20) Business Days to address such dispute. The Managed Services Oversight Council 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 Council.

If the Managed Services Oversight Council is unable to resolve a dispute within thirty (30) days of the first Managed Services Oversight Council 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.

7.9.2 Internal Escalation.The Parties will make efforts to first resolve internally any dispute, by escalating it to higher levels of management. If the disputed matter has not been resolved by the State Account Representative and Contractor Account Representative, the disputed matter will be reviewed by the Service Management Steering and Oversight Committee within fifteen (15) days of the delivery written notice by one Party to another.

If for whatever reason the Contractor and the State cannot resolve a dispute via the above escalation processes and procedures, Contractor and the State agree to choose a mutually agreeable third party neutral who shall mediate the dispute between the parties. The mediator chosen shall be an experienced mediator and shall not be: a current or former employee of either party or associated with any aspect of the Government of the State of Ohio; or associated with any equipment or software supplier; or 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 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 shall be non-binding and shall be confidential. Each party shall be represented in the mediation by a person with authority to settle the dispute. The parties shall participate in good faith in accordance with the recommendations of the mediator and shall follow procedures for mediation as

Page [60]


suggested by the mediator. All expense of the mediation, except expenses of the individual parties, shall be shared equally by the parties. The parties shall 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.

7.9.3 Escalation for Repetitive Service Level FailuresThe State may escalate repetitive service level failure to the Contractor’s executive sponsor, the Contractor’s Vice President for Public Sector, or the equivalent position.

7.9.4 No Termination or Suspension of Services or Payment.While any dispute is pending, the Contractor must continue its obligations under this Scope of Work and the applicable SOW, and not take any action that intentionally obstruct, delay, or reduce in any way the performance of such obligations. While any dispute is pending, the State will not interrupt or delay the payment of Services in whole or in part, other than Services that are the subject of the dispute.

7.10 Billing, Invoicing and Reporting

7.10.1 Billing Format and TimingContractor is to provide electronic billing by the first business day of each month for the Monthly Recurring Charge, and by the tenth day of each month for the preceding month’s additional or reduced charges.

7.10.2 Billing DetailIn support of the monthly electronic billing feed, the Contractor will include sufficient detail as to uniquely identify key billable items including (but not limited to): quantity of items, service types/description, resource units, and prices on a monthly basis with sufficient granularity to link to the State cost centers. The Contractor will derive the calculated monthly billed amount based on the baseline of billable Resource Units (the Monthly Recurring Charge), with the addition of any additional or reduced charges incurred during the preceding financial cycle (usually one month). The monthly billed amount will include the Monthly Recurring Charge adjusted by any additional or reduced charges, plus any additional out of scope services incurred during the month. The annual billed amount is equal to the total of the Monthly Recurring Charge, adjusted by additional or reduced charges, plus any additional out of scope services for a given fiscal year.

7.10.3 InvoicingThe Contractor agrees to meet with the State, after award of the Contract, to formalize the invoice requirements, including, but not limited to format, content, back up information, review processes, approval and timing considerations.

Page [61]


7.10.4 ReportingThe Contractor will implement and utilize measurement and monitoring tools and metrics as well as standard reporting procedures to measure, monitor and report the Contractor's performance of the Services against the applicable Service Level Specific Performance plus the Overall Performance Score and provide any other reports required under this Scope of Work. The Contractor will provide the State with access to the Contractor’s asset management reports used in performing the Services, and to on-line databases containing up-to-date information regarding the status of service problems, service requests and user inquiries. The Contractor also will provide the State with information and access to the measurement and monitoring reports and procedures utilized by the Contractor for purposes of audit verification. The State will not be required to pay for such measurement and monitoring tools or the resource utilization associated with their use.

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;

Monthly report(s) describing the State utilization of each particular type of Resource Unit, and comparing such utilization to then applicable baseline for each Resource Unit;

A number of other periodic reports requested by the State which the State reasonably determines are necessary and related to its use and understanding of the Services; and,

Reports that contain resource unit utilization data at a level of detail, and any other similar and related information that the State reasonably determines is necessary, to enable the State to verify and allocate accurately the Contractor's Charges under this Scope of Work to the various business units and divisions of the State and the other Eligible Recipients.

7.10.5 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

Page [62]


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.

7.10.6 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 date or other Deliverables caused by the Contractor or its agents, subcontractors or Third Party product or service providers.

7.11 Benchmarking

7.11.1 GeneralThe State may request the services of an independent Third Party (a “Benchmarker”) to compare the quality and price of the Services against the quality and price of well-managed operations performing services of a similar nature. The State uses the Benchmarker to validate that it is obtaining pricing and levels of service that are competitive with market rates, prices and service levels, given the nature, volume and type of Services provided by the Contractor hereunder (“Benchmarking”).

7.11.2 Frequency & Designation of Benchmarker The State may request Benchmarks during the term of the Contract at any time after completion

of Transition; no more frequently than every two years. For purposes of performing Benchmarking services, the Parties will designate a nationally

recognized Benchmarker as mutually agreeable as the Third Party Benchmarker. The Benchmarker will execute a tripartite agreement with the State and the Contractor, which

will at a minimum reflect the requirements set forth in this section. The Benchmarker will not be compensated on a contingency fee or incentive basis. The State and the Contractor will share equally the fees and expenses the Benchmarker charges

in conducting the Benchmark.

7.11.3 MethodologyThe State, the Contractor, and the Benchmarker will conduct the Benchmark in accordance with the following Benchmark process:

The Benchmarker will conduct the Benchmark using a Representative Sample. Prior to performing the comparison, the Benchmarker will provide and review the Benchmark

methodology with the State and the Contractor and will explain how each Comparator in the Representative Sample compares to the relevant normalization factors and the normalization approach that will be applied.

The State and the Contractor will mutually agree to the Benchmark methodology and any appropriate adjustments necessitated by differences in the Services provided to the State and the services provided to the Comparators in the Representative Sample.

Normalization is used by the Benchmarker to ensure appropriate adjustments are made to all data relating to each of the Comparators in the Representative Sample to account for any differences between the Services provided to the State and the services provided to the

Page [63]


respective Comparator that may impede a true “like-for-like” comparison. These normalization factors may include:

o Scope and nature of services;o Respective services environments;o The hardware or software used or required to provide the services;o Geographic disparity of services delivery and recipient locations; o Industry differences affecting information technology costs; o Economies of scale; o Size of investment;o Volume of services being provided;o Duration of the contractual commitment; o Service levels; o Complexity factors (including operating environment);o Contractor contract considerations and constraints;o Degree of standardization; o Financial engineering and allocations;o Financing provided by the Contractor; o Any additional or value added services performed by the Contractor and not received by

the Comparator(s);o The State or the Comparators’ unique requirements or limitations; o Terms and conditions under which the State received services; o Terms and conditions under which the Comparators received services; ando Any other relevant factors.

The Benchmarker will meet with the State and the Contractor to explain how the normalization was performed on each Comparator in the Representative Sample and will provide the State and the Contractor the pre adjustment and post adjustment Comparator data, while preserving the confidentiality of the Comparator.

Neither the State nor the Contractor will be required to disclose to the Benchmarker actual performance against Service Levels or other actual performance comparison.

The Representative Sample used by the Benchmarker for the Benchmark will be reasonably current (i.e., based on services provided to the State and the Comparators no more than 12 months prior to the start of the Benchmark).

During the 30 day period after the Benchmarker completes the data gathering, but before the Benchmarker has concluded the Benchmark analysis, the State and the Contractor will have an opportunity to verify the Benchmark conformed to the agreed Benchmark process.

The State and the Contractor agree to participate jointly in all discussions with the Benchmarker and to cooperate reasonably with the Benchmarker in the Benchmark activities; provided, however, in no event will the Contractor be required to provide the Benchmarker with the Contractor cost data or data from other Contractor customers.

Page [64]


The State and the Contractor agree that all information provided to or obtained from the Benchmarker will be provided to both the State and the Contractor, unless otherwise agreed.

The State and the Contractor agree that the Benchmark will be conducted in a manner that will not unreasonably disrupt either Party’s performance of the Services.

Any Benchmarker engaged by the State will not be a Direct Contractor Competitor and will agree in writing to be bound by the confidentiality and security provisions specified in this Scope of Work and specify that the data provided by the State and the Contractor may not be used for any purpose other than conducting the Benchmark of the Services. The Contractor will cooperate fully with the State and the Benchmarker and will provide access to the Benchmarker during such effort, at the Contractor’s cost and expense.

7.11.4 StandardThe Benchmark Level will be the highest price of the total charges attributable to the Benchmarked Services Towers within the top quartile among the Comparators comprising the Representative Sample. The Benchmarker will calculate the range of the first quartile using the Excel spreadsheet macro for quartile calculations.

7.11.5 Adjustments(a) If the Benchmark determines that the Charges paid by the State for all Services or for any Functional Services Area are less favorable to the State and the charges for the Benchmarked Services Area is in the aggregate equal to or less than the established 10 % dead band, then there will be no adjustment to such charges. If the Benchmark determines that the charges are in the aggregate higher than the Benchmark Level for such Services Area and the difference between the Benchmark Level and the charges for the Benchmarked Services Area is in the aggregate equal to or less than the established 10% dead band, then there will be no adjustment to such charges.

(b) If the Benchmark determines that the charges for any Benchmarked Functional Service Area are in the aggregate higher than the Benchmark Level for such Services Area and the difference between the Benchmark Level and the charges for the Benchmarked Services Area is in the aggregate greater than the established 10% dead band of the charges for such Services Area, then:

(c) At the Contractor’s option, the Contractor will automatically reduce such charges for that year to bring the charges for the Benchmarked Services Area within the established 10% dead band, provided that such reduction will be limited to no more than 5% of the current year’s Charges, as measured against the originally anticipated revenue for such year. As part of the current year’s benchmark, future year’s Charges will be adjusted so that they are no greater than the current year’s adjusted Charges; provided that the cumulative adjustments made to future year’s charges must be no more than 5% of that year’s Charges; or

(d) If the Contractor is unwilling to bring the charges for the Benchmarked Services Area within the established 10% dead band as described above, then the State may exercise its right to terminate for convenience the affected Benchmarked Services Area, but the State will be obligated to pay the

Page [65]


Contractor’s actual Wind-Down Expenses and unamortized investments in lieu of the Termination Charges.

(e) Any changes made to the charges pursuant to a Benchmark will take effect on a prospective basis 30 days following the Benchmarker’s delivery of the final Benchmark Results.

7.11.6 DisputesThe State and the Contractor will resolve any disagreement related to the Benchmark using the Dispute Resolution Process.

7.11.7 Charges ReviewIf the State elects not to conduct a Benchmark in any calendar year, the Parties must meet to review the charges and discuss potential equitable adjustments to the charges. Although any equitable adjustments should be mutual, the Parties are required to review the charges in light of the services provided in the event a Benchmark is not provided. Should the Parties agree to such an equitable adjustment, the Parties will execute an appropriate amendment.

7.12 Contractor Best Practices

7.12.1 GeneralThe Contractor acknowledges that the quality of the Services provided in certain Service areas can and will be improved during the Term and agrees that the Service Levels in such Service areas will be enhanced periodically in recognition of the anticipated improvement in service quality. The Contractor will improve the quality of the Services provided in such areas to meet or exceed the enhanced Service Levels and will do so at no additional charge to the State.

7.12.2 MeetingsIn conjunction with regularly scheduled operational meetings with State Personnel or a meeting of the Service Management Steering Committee, and in conjunction with continuous improvement requirements of this Contract, the Contractor may elect to sponsor a meeting to review recent or anticipated industry trends, emerging technologies, technology advancements, alternative processing approaches, new tools, methodologies or business processes (collectively “best practices”) that, at the State choosing, could alter the cost, efficiency, computing capacity, server density or otherwise drive efficiencies for both the State and the Contractor.

7.12.3 ObligationsThe Contractor will perform its obligation, including its obligations with respect to continuous improvement, in accordance with the common Six Sigma Quality Improvement Methodology (or similar quality management methodologies that the Contractor may utilize). The State is under no obligation to accept or implement these “best practices”, and absent a formal approval to implement these changes with a corresponding change order, the Contractor is under no obligation to implement these “best practices”.

Page [66]


7.13 SAS-70 ReportingOnce every calendar year, the Contractor will cause in the fourth quarter an annual Statement of Auditing Standards 70 (SAS-70) audit covering at least the preceding six month period, for the Contractor service locations or service types for which the Contractor, in its normal course of business, has conducted SAS-70 Type II audits and to the extent such reports are pertinent to the Services, to be completed by a nationally recognized firm qualified to perform such audits. The audit will be a multi-customer SAS-70 Type II covering the common processes controlled and performed by the Contractor at primary Contractor shared service locations in administering customer accounts. In the year Transition occurs, a SAS-70 audit will be provided only if Transition is completed in sufficient time to allow six months of Contractor performance prior to September 30. A copy of each of the resulting audit reports will be delivered to the State during the last quarter of each calendar year.

It is the sole obligation of the Contractor to remedy any issues, material weaknesses, or other items arising from these audits as they pertain to services or capabilities provided by the Contractor to the State in conjunction with the Statement(s) of Work in effect at the time of the Audit. The Contractor is to remedy these issues at no cost to the State. For items that arise as a result of State policies, procedures and activities, after mutual agreement on the underlying cause and remedial activity requirements and plan, State agrees to work, and under agreed terms, to effect the required changes to the Services delivery model to remediate issues discovered under a SAS-70 audit.

Page [67]


8 Managed Services SOWThe State’s PeopleSoft FIN, EPM, CRM, ELM and HCM systems, selected transaction processing functions, and related reporting systems are currently provided and managed by the State. In support of the State’s existing operations and in light of near term operating goals, it has been decided to migrate hosting of certain current functions to an external contractor to increase the overall agility, service levels and quality of the hosted services. Offerors should note that no offerors responding to the RFP have a pre-existing business relationship with the State for delivering these services.

8.1 General

8.1.1 Description and TermSection 8 contains the description of Services, as of the Effective Date, that the Contractor must provide under this SOW. The Contractor personnel will provide the following Services as described below in support of the in-scope Services for the Term of the Contract.

8.1.2 ChangesFrom time to time, the State may request that the Contractor perform discrete services related to, or in connection with, the Managed Services described in this RFP. Any such State requested Projects will be further described and carried-out pursuant to mutually agreed-upon Statements of Work.

Both Parties agree that this SOW may change over time. Specific State requested Projects (outside of the detailed Statements of Work contained herein, but delivered to the State via Ongoing Project Services as outlined in this RFP) that involve these services may be further described and arranged in one or more mutually agreed-upon Statements of Work. Regardless of the origin of these services, the Contractor must follow the Contract Change Procedures contained in Section 7 – Governance, which will be the mechanism to make changes to the Contract. Based on the need to incorporate the ongoing operation, maintenance and upgrades to these future Projects over the term of the Contract, the Contractor must support any ongoing Managed Services requirements associated with the delivery of these Projects to the Production environment (or applicable environment) under the Contractor proposed pricing included in the Contractor response as per the following:

Page [68]


8.2 Organization of Service Delivery AreasIn general, there are six areas under which the Contractor Services will be delivered:

Transition Services –Services designed to review the current state of the State systems, and operations sufficient to design and implement a computing environment to support current and anticipated demands of the State. Also included are Services designed to facilitate the successful migration from the current environment to future State architecture, if applicable.

Technology Updates and Refresh –Services designed to ensure that the State is operating on a contemporary, well architected, vendor supported and operationally documented and disciplined Technology infrastructure and in keeping with the Contractor’s delivery of the specified Statement(s) of Work in effect, per conditions specified under the respective Service Level Agreements.

Steady State Run Services – Services and operations designed to support the ongoing operations of the in-scope computing environments.

Infrastructure Management Services – Services designed to administer and support high performance, high quality and high availability (to the extent set forth in this SOW) computing infrastructure required by the State.

Program Management Services – Services designed to help overall continuity and viability of the computing infrastructure, adoption of new initiatives, support of future growth and other needs as they pertain to the provided computing infrastructure.

Termination Services – Services designed to assist the State at the conclusion of the contract term (either through expiration, cancellation or termination) to migrate the services back to the State or a new contractor as designated by the State.

8.3 Transition Services

8.3.1 GeneralThe Contractor will be responsible for supporting the migration of supported systems, system components, IT infrastructure and related operational support in transitioning from the State’s existing environment to a mutually agreed upon environment(s) to enable the Services to be provided under the Scope of Work to the extent defined and agreed within this SOW. The Contractor’s general responsibilities with respect to Transition Services include the tasks, activities and responsibilities listed below.

8.3.2 Transition ManagementDuring the period beginning on the Effective Date and ending upon completion of all Contractor responsibilities as identified in the Transition Plan, the Contractor will plan, prepare for and conduct the migration of certain information systems operations (the “Transition”). Transition will include the migration of systems and related operational support from currently existing facilities, locations and personnel to long-term facility/location as mutually agreed between the Parties.

Page [69]


The Contractor will:

o Coordinate with the State and the State network provider to schedule the installation of the WAN circuit into the Contractor Service Delivery Center;

o Make available space, power and environmental controls for the WAN provider’s equipment and provide technical assistance for the WAN equipment located in the Contractor’s facilities;

o Implement processes as to not otherwise disrupt the State business operations, including the interfaces between the State and various third-parties and the OSSP that will be in progress during the transition period;

o Develop a plan to bring the existing IT helpdesk functionality to 9.x CRM application by summer 2009.

o The Contractor must assess and provide a recommendation as to whether the IT Help Desk application should be brought within the new OSSP call center CRM application to reduce support costs and so that only one CRM application/version is supported;

o Specify costs and effort associated with Transition and otherwise performing such migration tasks as are necessary to enable the Contractor to provide the Services, including following the Transition; and

o Ensure that printing of checks can continue to be performed by the State Printing Office within the Department of Administrative Services.

The State will:

o Obtain and provide current information, data and documentation related to the Transition (for example, Third Party supplier and the Contractor information, facility data, inventory data, existing operational processes and procedures, systems documentation, configuration documentation), decisions and approvals, within the agreed time period;

o Establish communications lines and WAN network connections;

o Assist the Contractor in identifying, addressing and resolving deviations from the Transition Plan and any business and technical issues that may impact the Transition; and

o Develop the Transition meetings (i.e., planning, review and status) schedule with the Contractor, including the frequency and location, and attend such meetings in accordance with the established schedule.

8.3.3 Transition PlanTransition will be conducted in accordance with a written plan (the “Transition Plan”) which will include the following items. The Transition Plan will be created as a deliverable. The Contractor will be

Page [70]


responsible for revising and finalizing the Transition Plan, provided that: (1) the Contractor will cooperate and work closely with the State in finalizing the Transition Plan (including incorporating the State agreed comments); and (2) the final Transition Plan will be subject to written approval by the State.

The Transition Plan will contain:

o A description of the IT operations being migrated;

o Baseline performance attributes of the system/environment being migrated to validate that system performance post-migration is not adversely impacted;

o A description of the methods and procedures, personnel and organization the Contractor will use to perform the Transition;

o A schedule of migration activities;

o A detailed description of the respective roles and responsibilities of the State and the Contractor;

o Such other information and planning as are necessary so that the Transition takes place on schedule and without disruption to the State operations;

o A definition of completion criteria for each phase of the Transition Plan, so that the Parties may objectively determine when such phases have been completed in accordance with the plan;

o A process by which the State may require the Contractor to reschedule all or any part of the Transition if the State determines that such Transition, or any part of such Transition, poses a risk or hazard to the State’s business interests and allowing the State to require the Contractor to reschedule all or any part of the Transition for any other reason; and

o Validation of successful Transition inclusive of user acceptance and assessment of acceptable performance with respect to comparison to baseline performance attributes collected during preceding phases (i.e., design, build, test) outlined herein.

The State will:

o Reasonably cooperate with the Contractor to assist with the completion of the Transition; and

o Approve or reject the completion of each phase of the Transition Plan in accordance with the acceptance criteria after written notice from the Contractor that it considers such phase complete, such approval not to be unreasonably withheld. If the Contractor does not receive written notice of such approval or rejection within forty-five (45) days of receipt of the written notice, the phase will be deemed accepted by the State.

Page [71]


8.3.4 Transition ProcessNo functionality of the IT operations being transitioned will be disabled until the new location is demonstrated to materially conform to the requirements set forth in any related Statements of Work, operational performs and is performing conformant to agreed-upon Service Levels, and has been accepted by the State.

As part of Transition, the Contractor will:

o Inventory, track and report all software on supported servers.

o Report CPU counts on supported servers.

o Obtain the required consents necessary to transition such software on a Supported server at no cost to the State.

The State reserves the right to monitor, test and otherwise participate in the Transition as described in the Transition Plan. The State and the Contractor will develop a mutually agreed upon responsibility matrix for discrete activities tasks as part of the transition planning process. The State will provide availability to its Application group to the Contractor according to such agreed-to responsibility matrix in the Transition Plan.

8.3.5 Transition Planning Services General. Planning Services perform the following function:

o Define and Prioritize.

o Define stakeholder goals and expectations.

o Define high-level requirements and the scope of Transition.

Plan and Analyze. The tasks and activities to be performed by the Contractor as part of the planning and analyzing phase of the existing computing environment which includes the following:

o The Contractor will be responsible for managing the process and preparing a scope and operations portion of the Transition Plan which will include assessing the resource requirements (either hardware, software or personnel), time requirements, known impact or dependencies on other Projects, and other information as required as mutually agreed to by the Parties. In addition, such Transition Plan will explore solution development or alternative sourcing and implementation options including, where applicable, providing build versus buy analysis and support.

o The Contractor will provide support to the State in the creation and evaluation of proposed strategies and standards to coordinate information and technical architecture across the State business units and to develop recommendations on information and technology use within the State.

Page [72]


o The Contractor will define high-level solution blueprints and operational/technical change plan for each major functional or service domain areas (a combination of “user/services type”, “file server”, “compute server”, etc.).

o The Contractor will conduct progress reviews with appropriate the State personnel.

o The Contractor will prepare a detailed transition plan which includes an estimate of the schedule and labor for the design, development, implementation and training required for each phase contained in the plan. Each transition plan will, at a minimum: (i) include schedules that specify a detailed level of activity, including the planned start dates, completion dates, hours and other required resources for activities to be performed by the Contractor (and the State where applicable) pursuant to the phase for which such Transition Plan was developed; (ii) identify any pre-existing software components (e.g., code libraries) and tools to be used; (iii) licensing or purchase requirements of any Third Party components, tools or software elements including Systems software, operational tools and instrumentation, operational productivity aids and other tools required to deliver the solution to the State; (iv) include a detailed list of the deliverables and milestones (with planned delivery/completion dates) and the phase management reports that will be provided; (v) describe any assumptions made in compiling the plan; and (vi) identify any the State dependencies or personnel requirement assumptions.

o The Contractor will establish baseline performance levels of supported servers, processes and other measurable elements of system performance for the current “status-quo” environment to be used as the basis for performance validation during the Transition Period.

o Identify potential risks due to uncertainty with the solution’s complexity and feasibility.

o Coordinate and confirm the State approval of phase requirements as stated above.

8.3.6 Environment Design-Build ServicesThe Contractor will develop and build technical and functional designs for each service domain of the computing environment. The environment design and build Services will also include the following:

Design. The build designs will include, where applicable based on the size, complexity and requirements of the system(s), Supported server(s) or Application(s), design of files, databases, forms, user interfaces, reports, security, system performance and availability instrumentation, audit trails of the transactions processed, provision for parallel testing, development of fallback procedures, provision for recovery procedures from production failures, disaster recovery procedures, creation of job scheduling, and provision for on-line viewing of reports. As part of the design process, the Contractor must also:

o Analyze related State servers and environments to identify any additional or alternative IT solution requirements required to deliver the Services (including proposed optimization of the State’s LAN/MAN/WAN infrastructure if applicable)

Page [73]


o Assess current IT solution gaps and dependencies.

o Create IT system/solution designs to support solution requirements as follows:

Design user interaction model which defines applicable standards, solution prototypes, and virtualization designs.

Design reports and forms.

Design integrated solution components and interfaces to external systems.

Design logical environment, data conversions/migrations, processes and procedures as agreed necessary.

o Compile and maintain solution incident lists.

o Document design specifications and work with the State to create applicable completion criteria in accordance with meeting Production Processing and Defined SLA requirements.

o Conduct quality and progress reviews with appropriate State personnel.

o Establish assembly, configuration, environmental, performance, and user acceptance test plans.

o Coordinate and confirm State approval of solution design specifications and applicable completion criteria.

o Determine and identify relevant Baseline system performance profiles or capabilities sufficient to design a robust solution that complies with this SOW and the Service Levels in the Contractor environment as well as to serve as the basis for performance comparisons following Transition.

o Provide the State with regular reports tracking the progress of the Contractor’s design work. In addition, the Contractor must provide timely responses to State requests for information and reports necessary to provide updates to State business units and stakeholders.

Build. The Contractor will be responsible for generating systems environments required to complete and implement each supported computing platform in support of the in-scope Applications as part of delivery of the overall Managed Service. The Contractor will provision for the development of operational documentation sufficient to operate the supported environment at agreed-upon Service Levels and incorporate the use of documentation standards, reviews, and audit trails, including release control. User walk-through of the systems environment will be reasonably provided upon request. The Contractor’s documentation must include the creation and testing of test and production procedures and job schedules, as appropriate. The Contractor must also perform the following tasks and activities in connection with building systems environments:

Page [74]


o Perform detailed technical design as agreed appropriate.

o Build solution components to support approved design specifications as follows:

Configure and customize solution user interfaces, process and procedures as required.

Configure and customize solution environments including CPU, disk and memory configurations.

Configure and customize integrated solution components and interfaces to external systems.

o Coordinate with the State Infrastructure Management experts to implement other physical environmental requirements and designs.

o Document solution and refine applicable user acceptance/validation criteria.

o Develop any applicable State-specific training materials, as follows:

Perform training needs analysis based on the State requirements that have been identified to the Contractor;

Determine the training material/method of delivery design with the State;

Develop training material to support the agreed-upon approach and methods of delivery.

o Coordinate with State infrastructure management experts to implement required technology environment changes as mutually agreed.

o Compile and maintain incident lists per the ITIL requirements as defined in Section 4.4.

o Develop environments in accordance with State strategies, principles, and standards relating to technical, data and Applications architectures as set forth in this SOW.

o Conduct build progress reviews with appropriate State personnel.

o Coordinate and confirm the State approval of solution components and verification of applicable completion criteria for transition into test/validation activities.

o Provide the State with reports on a weekly basis tracking the progress of the Contractor’s performance of build activities and deliverables. In addition, the Contractor will provide timely responses to the State requests for information and reports necessary to provide updates to the State business units and stakeholders, as reasonably required.

Page [75]


Test/Acceptance. The supported environment will be subject to a formal testing and acceptance process as stated in this SOW, that uses objective and thorough test or validation criteria established by the Parties that will allow the Parties to verify that each Project meets the specified functional, technical and where appropriate, performance requirements. The testing and acceptance process will be developed for each Project as soon as possible after establishing the business and user requirements. The testing and acceptance process will include a capability for tracking and correcting problems. The tasks and activities that the Contractor will perform as part of the testing and acceptance process also include the following:

o Develop and maintain test data repositories as agreed appropriate;

o Develop test plans, scripts, cases and schedules as agreed appropriate;

o Perform the following testing activities for in-scope components and assess quality and completeness of results:

System test/assembly.

Product test including integration/interface testing and regression testing new releases of existing in-scope solutions.

o Provide testing as required to perform the system and user acceptance testing work for the supported servers, and where appropriate performance validation testing period. The testing will be designed and maintained by the Contractor so that build and subsequent testing activities will be sufficient to verify that End-User perceived performance on the Contractor provided environment is consistent with the pre-transfer baseline and to minimize incidents associated with the migration of environments to the Contractor;

o Conduct quality and progress reviews with appropriate State personnel;

o Coordinate and confirm State approval of solution components and verification of applicable completion criteria for transition into deployment and production (steady State) use; and

o Provide the State with reports on a weekly basis tracking the progress of the Contractor’s performance of testing work, or in the case of user acceptance testing, support of State activities. In addition, the Contractor will provide timely responses to State requests for information and reports necessary to provide updates to State business units and stakeholders, as reasonably required. The Contractor will also provide the State with a services connection portal that tracks progress of the Contractor’s performance of testing work upon request.

Deploy. The Contractor will be responsible for the production deployment and roll-out of any newly developed environments over the term of the Contract. Deployment includes identification of interfaces and any required data migrations, installation and testing of, installed Systems software, and any required testing to achieve the proper roll-out of the infrastructure computing environment(s). The Contractor will comply with the State required implementation

Page [76]


and deployment procedures as set forth in this SOW. This may include, network laboratory testing, data migration procedures, the use of any pre-production or pseudo-production environment prior to production migration. The Contractor will submit to the State, for the State approval, in accordance with this SOW, a written deployment plan describing the Contractor’s plan to manage each such implementation. The tasks and activities to be performed by the Contractor as part of the Deployment Services also include the following:

o Execute required migrations.

o Perform required data matching activities and error reporting.

o Document incidents and provide to the State for resolution.

o Coordinate and confirm the State approval of data conversion results as stated in the SOW.

o Conduct production pilot and fine tune solution as agreed appropriate.

o Compile and maintain solution incident lists.

o Support communication effort.

o Identify required communication recipients and communicate deployment activities to deployment stakeholders.

o Evaluate detailed communication feedback from recipients and stakeholders.

o Identify the effectiveness of and need for additional communication.

o Determine the requirements for, and assist the State in the development of End User training for the computing system(s) or environment(s) resulting from Transition, including the roll-out of workshops, self-study guides and computer-based training and train-the trainer activities, based on the State requirements provided to the Contractor.

o Support train-the-trainer activities as mutually agreed in the Transition Plan.

o Confirm timeframe, type, content, and target user audience of planned training.

o Perform training with the State trainers’ audiences adequate to perform their operational responsibilities.

o Assess the effect and value of conducted training and cooperate to resolve issues identified.

o Conduct weekly quality and progress reviews with appropriate the State personnel.

Page [77]


o Develop, and thereafter maintain and make available to the State, documentation gathered throughout the project's life and allow for re-use of such documentation for future Projects.

o Transition the State data center to Service Delivery center solution support to steady-state operations maintenance team as provided in the Transition Plan.

8.3.7 Existing Personnel ConsiderationsDuring the course of the transition period, the Contractor will have access to existing State personnel performing “current state” operational responsibilities until the conclusion of the transition period and coincident with the production acceptance of the system into the Steady State environment and delivery of ongoing managed services under this statement of work. During this period, the Contractor is encouraged to review and assess existing State personnel and determine the suitability of these personnel in performing these services as part of the Contractor managed services offering. Based on mutual interest of the employee, Contractor and State, the State will explore personnel transfer considerations and strive to affect any personnel transfers deemed appropriate. In the event of any personnel transfer, under no circumstances will the terms, conditions, statement(s) of work or service level agreement(s) contained herein be altered as a result of this transfer. The Contractor is under no obligation to consider transfer of any contractors performing work on behalf of the state for in-scope services.

The following table represents an initial view of the roles currently being provided by State personnel.

IT Functions

PM/Strategy/Planning

Account Management

Technical Architecture

Application Development – Finance

Functional/BA

Dev/Test (bug fixes, enhancements)

Application Development – HR

Functional/BA

Dev/Test (bug fixes, enhancements)

Application. Develop – Reporting and Data Architecture

Functional/BA/Dev/Test

QA/Testing

Application Architecture/DBA/ Sys Admin

Data Center Services/Physical Infra.

Change Management

Security (not CISO function)

Readiness (Training)

Help Desk (Tier 1)

Page [78]


OAKS Management

OAKS Administrative Support

8.4 Technology Update and Refresh Services

8.4.1 Technology Review and InventoryThe Contractor is to review the current environment inclusive of hardware, network, software, infrastructure, security, back-up and other ancillary technical components as described in Section 6 – Technology Overview and develop a plan to assume overall operational responsibility for the existing environments. Based on the purchase schedules (most purchased in late 2005/early 2006) and anticipated useful life of the technology elements in this section and currently in use at the State, the State assumes that the underlying technology will be replaced during the term of the Contract.

8.4.2 Technology Refresh PlanThe Contractor will create a comprehensive technology refresh plan that is aligned with contemporary best practices, and in keeping with the achievement of Service Level Agreements (SLAs) contained in this RFP. Based on the review and approval by the State, this plan will be implemented as part of the Transition Services as outlined in Section 8.3. Based on Contractor best practices, and in keeping with the Contractor attainment of the defined SLAs, the Contractor must propose a specific approach using one of the following (or propose an alternate business practice with a detailed description and rationale):

Replacement of existing hardware at service commencement to ensure overall continuity and minimization of late-term disruptions in service due to hardware upgrades/replacements;

Phased replacement of existing hardware over the term of the Contract to best leverage existing State investment in technology components while minimizing any disruptions in service associated with the implementation of the technology upgrade plan; or

Total replacement of existing technology elements upon reaching practical service life and full depreciation in order to maximize the State investment in existing technology elements wherever possible, while minimizing any disruptions in service associated with the technology upgrade plan.

In any case, Contractors are specifically required as part of the technology upgrade plan to:

Provide and implement a plan to repurpose existing technology elements (whether production or non-production) to support “non-production” uses such as training, development, testing, demonstration and other uses until the useful life of the technology element has been reached;

Promptly return any unused or not required technology elements to the State that are currently owned and managed by the State upon their replacement in the Managed Services environment;

Page [79]


Identify any contractual or other State liabilities associated with purchased technology elements associated with this Contract as a result of the technology upgrade plan, including any maintenance, lease, outright purchase or other costs that the State may incur; and

Price and include at least one (1) complete technology refresh coincident with the initial five (5) year Contract term. The technology refresh costs must be included in RFP pricing schedules as per the instructions contained in the Cost Summary.

8.5 Steady-State Operations and Maintenance ServicesThe Parties agree that the Steady State Operations and Maintenance Services under this Scope of Work will pertain to the period following the completion of the Transition of the supported computing environment to the Contractor to the completion of the contracted period, upon obtaining authorization from the State based on satisfying conditions of transfer and materially conforming to agreed-upon Service Levels. The Contractor will, through ongoing support and maintenance control processes, maintain support of the solutions developed by the Contractor during the term of the Contract. Such ongoing support and maintenance will include the following tasks and activities.

8.5.1 Level 2 and 3 SupportThe State will maintain a Level 1 help desk designed to respond to user needs and inquiries and to the extent possible, resolve them with limited involvement from the Contractor. To the extent that the Level 1 help desk is unable to resolve technical or functional questions or issues from the user community, the Contractor will provide Level 2 and 3 help desk functions as a service to the Level 1 help desk and the State.

Contractor tasks include:

To the extent incidents cannot be resolved by a centralized State Service Desk, tracking, monitoring, responding to requests and incidents and resolving incidents consistent with the established Service Levels and referring, as set forth in the Run Book or other supporting documents, requests to break/fix support resources for additional assistance;

Providing documentation for the Contractor’s development of or modifications to the Contractor Service Desk to help minimize transfers to specialized support;

Providing the State with an updated list of Contractor-provided Level 2 Support personnel or “on call” personnel who are responsible for Level 3 Support, including contact phone numbers; and

Working to correct environment defects or problems that require environment code or operational modifications.

The State will:

Be responsible for all end-user training (hardware and software); For in-scope State-retained systems, provide systems status information to the Contractor

Service Desk and updates as they occur. The Contractor will maintain such information as set forth in the Run Book or other supporting documents;

Page [80]


Maintain and distribute a State contact list, including names and telephone, mobile/pager and fax numbers, for use by Contractor Service Desk staff to contact appropriate State personnel for problem determination assistance and escalation and ensure such personnel are available as required;

Assist the Contractor in establishing call prioritization guidelines and escalation procedures; Ensure end-users have a basic level of understanding of the Contractor Service Delivery

processes and adhere to such processes for accessing the Services; Communicate support responsibilities and procedures to the State Single Point of Contact and

Third Party service providers (for example, providing call status and resolution to the Contractor Service Desk) and ensure adherence to such procedures;

Assist the Contractor, as requested and in a time frame commensurate with the assigned problem Priority Code and associated Service Level commitment, in the resolution of recurring problems which are the result of end-user error;

Resolve any the State Third Party service provider performance problems affecting the Contractor's provision of the Services;

Be responsible for all the State Third Party support costs (for example, help lines or additional Application functional or technical support); and

Be responsible for the resolution or closure of all calls related to products and services that are not within the Services.

8.5.2 Break/Fix Support. The Contractor will:

Track, monitor and provide remediation for solution defects and incidents requiring system configuration or in-scope environment code or configuration changes;

Identify and implement required system or configuration changes to address solution defects. 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;

Test configuration changes to confirm resolution of defects; Identify, test, install and implement Third Party contractor-supplied patches and fixes for Third

Party contractor-supplied packaged systems software (including OS, BIOS, microcode, patches, service packs and similar), as well as new releases. If a new release contains new features and functionalities, the Parties may agree to additional services required to enable or disable such features and functions (e.g., configuration, gap analysis, etc.) as part of any separate Project-related enhancement service; and

Comply with any State security mandated patches or system levels to the extent and system enhancement turnaround time required given the nature of the security mandate.

8.5.3 Environment Technical SupportThe Contractor will:

Page [81]


Maintain environment performance, availability and stability of the production environments with the hardware resources.

Identify to the State any issues that adversely impact the State in-scope environment and operational requirements and that require analysis of the technical components of the system, including the applications, databases, ancillary and systems software and hardware.

Conduct post-mortem reviews with the State for corrections to technical issues with in-scope environments or operations and incorporate resulting changes into ongoing continuous improvement initiatives.

8.5.4 System/Environment Administration SupportThe Contractor will:

Monitor environments, apply patches, and administer the system logs. Perform various technical activities such as system code/object migrations, patch

implementations, log administration, various data copies and exports, and general assistance in incident resolution such that migrations into production will be executed at agreed periodic intervals and other production changes will be scheduled during the maintenance window.

If requested in writing by the State, support multiple release levels of System software/hardware elements for in-scope Services, provided that such support does not impair the Contractor’s ability to meet the Service Levels.

Maintain an e-mail listing for each logical supported server resource. When the supported server resource has an unscheduled outage or reduction in performance, the Contractor must notify the supported server user list based on outage/service reduction and promptly after supported server/service restoration in accordance with the Run Book or other supporting documents.

Allow User access to the Contractor trouble ticketing system that contains all open tickets managed by the Contractor for that User (providing estimate to complete ticket, ticket prioritization, etc.) as well as all Service Level impacting items, whether State or Contractor initiated, in accordance with the Run Book or other supporting documents.

8.5.5 Environment Preventive Maintenance The Contractor will:

Perform environment/supported server tuning, code restructuring, and provide tools and other efforts to help improve the efficiency and reliability of environments and to help reduce ongoing maintenance requirements.

Assess, develop, and recommend opportunities to reduce (or avoid) costs associated with environment support and operations.

Provide appropriate Contractor-related data for periodic State analysis and review of resources deployed for preventive maintenance and planning preventive maintenance.

Monitor and analyze trends to identify potential issues and follow-up on recurring problems.

Page [82]


Maintain environments in accordance with the State strategies, principles, and standards relating to technical, data and Applications architectures as agreed-upon in this SOW, Projects, or the Run Book or other supporting documents.

Install Systems software upgrades and enhancements for updates or revisions (i.e. 1.x, where x is the update/revision) as necessary to maintain the operability of the Services and implement technology changes (e.g., Systems software upgrades or new scheduling software). Included in the scope of such adaptive development work is testing new interfaces to Applications. The Contractor will install Systems software upgrades and enhancement for versions (i.e. X.1, where X is the version) as a Project approved by the State.

Support the various service tiers (i.e., 11x5, 16x5, 24x7, compute processing (intermittent continuous operations on-demand)) production-availability schedule as agreed with the State and Authorized Users or in accordance with the Run Book or other supporting documents.

Coordinate with designated State production staff, to manage production schedules. Update access and parameter or environment configurations contained within in-scope

environments, where applicable. Establish a production calendar inclusive of daily and periodic maintenance activities. Generate and provide access to the State to daily production control and scheduling reports,

including the production of monthly summary reports that track the progress of the Contractor’s performance of maintenance work.

Provide timely responses to State requests for information and reports necessary to provide updates to the State business units and stakeholders.

Implement and monitor the Management Services operations. Monitor operations for correctness and adherence to agreed quality, performance and

availability criteria as set forth in the Run Book or other supporting documents. Perform batch monitoring and restart as follows:

o Verify batch jobs start as scheduled;o Monitor scheduled production batch jobs; o Resolve batch scheduling conflicts;

Monitor scheduler related incidents and develop and recommend changes to the scheduler database;

Schedule batch jobs, as requested by the State, that require expedited execution; Notify the State as required in the Run Book or other supporting documentation; and, Perform job restart, as necessary, in accordance with resolution and restart procedures. Support production staff (both the State and Contractor) to create and adapt IT operational

processes and procedures related to the in-scope environments. Perform backup processes as follows:

Type Description Scheduled TimingBaseline Pre-production image OnceDaily Incremental Files Data changes during the period DailyFull Data Files All resident data files Weekly (weekend)Applications All application files Monthly and Immediately

Page [83]


preceding and following any updates to application software

Pre-Production InitiationsAll initiation files during the initiation period Daily

Operating System and Related Infrastructure software

All O/S configuration files and related Infrastructure software Monthly

Database All Database Weekly (weekend)

Fall Back Copy

At request of State when a change is made to a customer system a copy will be made before the change. As needed

Maintain backup retention periods as follows

Description Retention PeriodBaseline Until first annual + 1 monthDaily 6 DaysWeekly 4 WeeksMonthly 12 MonthsAnnual 7 Years

Communicate appropriately with the State designees, authorized users and Third Party vendors. Perform ad hoc operations reporting as agreed by the Parties. Prioritize support functions during a crisis as set forth in the Run Book or other supporting

documents. Serve as primary point of contact and lead IT operations support for the in-scope environments. Act as a resource with respect to knowledge and information sharing regarding the supported

computing environment, as required by the State authorized entities and end-users. Provide information and consulting support with respect to system performance, Provide assistance with interface file testing, design appropriate test environments, and maintain system documentation.

8.5.6 ReportingThe Contractor will:

Provide the State with summary reports, on a monthly basis, to track the progress of the Contractor’s performance on maintenance work and provide access to daily reports to confirm progress against agreed-upon operational and maintenance calendars as set forth in the Run Book or other supporting documents. In addition, the Contractor will provide timely responses to State requests for information and reports necessary to provide updates to the State business units and stakeholder constituencies. The Contractor must provide periodic reporting of software and CPU counts on supported servers as prescribed in the Run Book or other supporting documents.

Page [84]


For production or customer impacting incidents that result in a down system, or the unavailability of a production component, the Contractor must report progress based on the Service Level Agreement until the incident is corrected or the State agrees that the incident causing the unavailability situation has been corrected. In all cases, the minimum reporting standard will be dictated by the Service Level Agreement for the impacted Services.

8.5.7 Discretionary ServicesBased on the State’s experience with the management and ongoing operations of the PeopleSoft environments, the State is requiring the Contractor to provide the capability to address minor alterations or enhancements (usually less than 100 hours per occurrence) to Applications within the scope of the Managed Services. Due to the sporadic nature of these requirements (e.g., minor display field changes, edits, reports, etc.), the State may require the Contractor to provide these services as needed.

The Parties will agree to a resource plan to support discretionary services in order to maximize personnel continuity.

The Contractor must include, in their proposed annual cost for Managed Services, an initial pool of eight thousand (8,000) hours to be used in conjunction with the Contractor’s Rate Card. The hours will be pro-rated for the first Contract fiscal year commencing July 1st. The Contractor and State will meet at the conclusion of the first fiscal year of Contract execution to review this discretionary hour pool and make adjustments as required. As part of this review, and coincident with monthly Managed Services Management Council meetings, the Contractor will provide a schedule of discretionary hours consumed (by activity, resource and Project) and a forecast of remaining hours and activities. Customary Project/service resource models must be used to serve as the basis for the estimating usage of the 8,000 hour pool.

Ad-Hoc Requests may be required under this discretionary hour pool. The following provide an example of ad-hoc requests:

Ad-hoc requests require no modification, configuration, or customization of the environments. The Contractor will provide service on request to end-users in accordance with the Run Book or

other supporting documents. Requests will normally be made through the State Level 1 Service Desk to effectively manage demand.

Routine tracking procedures will provide visibility of all ad-hoc requests in accordance with the Run Book or other supporting documents. The Contractor and the State will develop a prioritization approach for ad-hoc requests based upon business impact and document such process in the Run Book or other supporting documents.

8.6 Infrastructure Management ServicesThe Contractor will be responsible for managing infrastructure required to support the in-scope environments to the extent defined and agreed in this SOW. The Contractor’s general responsibilities with respect to Infrastructure Management include the following tasks, activities and responsibilities listed below.

Page [85]


8.6.1 Data Center ServicesThe Contractor will provide a managed Contractor Service Delivery Center for supported servers, a network Contractor Service Delivery Center LAN, and storage and backup devices, within the Baselines, as stated below. The Contractor will purchase all hardware necessary to support such Contractor Service Delivery Center within the Baselines.

Intel supported servers: means a supported server running any variant of a Windows or Linux operating system on an Intel-based platform.

Unix supported servers: means a supported server running an OEM variant of Unix-based operating system (other than Linux on an Intel supported server).

There are servers that perform production and non-production functions that fall into the following five (5) categories:

Infrastructure -- a supported server that is primarily operating software tools used to support the overall environment or tools used by administrators or developers

File and Print -- a supported server that is primarily hosting files and data or used for printing services for end-users

Web server – a supported server that is primarily hosting software, such as Apache, that provide web services;

Application server – a supported server that is primarily hosting business Application software; and

Database server – a supported server that is primarily operating database subsystems and hosting database instances.

All supported servers identified as production servers and any direct replacements must have a single image of a Windows, Linux or Unix operating system regardless of the number of actual images on such supported servers and any reduced charges to production servers will be based upon a single image Resource Unit. All supported servers identified as non-production servers, any direct replacements, as well as all additional supported servers added through the Additional Charge methodology, or subsequently removed through the reduced charge methodology, will have a single image of a Windows, Linux or Unix operating system and the application of additional or reduced charges will be based upon the actual number of images on each such supported server. There will be no additional charges for the addition of a non-production server above the applicable Baseline volume to the extent that a production server of the same category (i.e. Infrastructure, File and Print, Web, Application or Database) has been removed from Service and the State is then receiving a reduced charge for such supported server, however, the State would no longer be entitled to the reduced charge for such production server.

8.6.2 Managed HostingThe Contractor will:

Page [86]


Manage the Contractor Service Delivery Center as well as the capabilities within the Contractor Service Delivery Center itself including air conditioning, power and cleaning;

Support the Contractor Service Delivery Center redundancy approach as agreed to help prevent loss of system availability;

Support physical facility planning; Provide a primary facility contact at each hosting location, including details on access, facility

security, and environments hosted at facility, and other facility specific requirements as set forth in the Run Book or other supporting documents;

Support media management including maintaining, tracking, and offsite storage of media used by Storage Devices on standard schedules;

Provide remote management staff to support the physical needs of environment including changing media, system start up and shut down, as well as physical inspection and mediation of the systems;

Support disaster recovery activities as defined in this SOW; Support Service Levels as agreed in accordance with this RFP; and Support the various system instances required as defined in the Current Technology Overview

Section 6.

The State will:

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

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

8.6.3 Security ServicesThe Contractor will be responsible for maintaining information security in environments under the Contractor’s management and in accordance with State IT Security Policies. The Contractor will implement an information security policy and security capability as set forth in this SOW.

The State acknowledges that the current model for OAKS PeopleSoft security is not in line with industry best practices. When OAKS was implemented, the State did not have an Enterprise Directory resulting in LDAP integration not being completed. Additionally, PeopleSoft Portal, while licensed by the State, was not implemented. As a result, a single sign-on solution does not exist for the PeopleSoft FIN and HCM applications. A custom interface was built to maintain user security synchronization between HCM and EPM. The offeror must include, in their response, recommendations to improve this security model after the transition period is complete.

Based on the Contractor’s standard service center security processes, the Contractor’s responsibilities with respect to security Services will also include the following:

Page [87]


Provide vulnerability management Services for the Contractor’s internal secure network connection, including supporting remediation for identified vulnerabilities as agreed.

Support the State IT Security Policies. Develop, maintain, update, and implement security procedures, with State review and approval,

including physical access strategies and standards, ID approval procedures and a breach of security action plan.

Manage and administer access to the systems, LAN, System software, systems files and State data, excluding end-users.

Provide support in implementation of programs to educate State and Contractor end-users and staff on security policies and compliance.

Install and update Systems software security, assign and reset passwords per established procedures, provide the State access to create User ID's, suspend and delete inactive logon IDs, research system security problems, maintain network access authority, assist in processing State security requests, perform security reviews to confirm that adequate security procedures are in place on an ongoing basis, and provide incident investigation support (with State support), and provide environment and supported server security support and technical advice.

Develop, implement, and maintain a set of automated and manual processes to ensure that data access rules are not compromised.

Perform physical security functions (e.g., identification badge controls, alarm responses) at the facilities under the Contractor’s control.

Prepare an Information Security Controls Document. This document is the security document that is used to capture the security policies and technical controls that the Contractor will implement, as requested by the State, on Contractor managed systems, supported servers and the LAN within the scope of this SOW. The Contractor will submit a draft document for State review and approval during the transition period.

The State will:

Develop, maintain and update the State IT Security Policies, including applicable State information risk policies, standards and procedures.

Provide a State Single Point of Contact with responsibility for account security audits; Support intrusion detection and prevention and vulnerability scanning pursuant to State IT

Security Policies; Provide the State security audit findings material for the Services based upon the security

policies, standards and practices in effect as of the Effective Date and any subsequent updates. Assist the Contractor in performing a baseline inventory of access IDs for the systems for which

the Contractor has security responsibility; Authorize User IDs and passwords for the State personnel for the Systems software, software

tools and network infrastructure systems and devices under Contractor management; Approve non-expiring passwords and policy exception requests, as appropriate.

Page [88]


8.6.4 IT Network Connectivity & Monitoring ServicesThe Contractor will be responsible for Contractor Service Delivery Center network operations for supported servers, Storage Devices and Data Center LAN. The Contractor will:

Provide infrastructure monitoring Services that consist of the following:o Event management and automating the continuous monitoring of systems based on

pre-defined parameters and thresholds and feeding of events into fault management tools.

o Systems monitoring across system components including identifying unauthorized access to the network, and reporting outages via the management tool set.

o Event correlation for fault managed devices and mapping of the relationship for multiple identified events.

Provide engineering support at agreed levels for addressing, mediating and managing critical hardware and software incidents.

Maintain and provide LAN documentation for the Contractor’s areas of responsibility and participating with the State in maintaining overall network documentation.

Maintain and support LAN components within the Contractor’s areas of responsibility, including:o Supporting network and supported server software required and provided protocols and

security techniques as well as standard data access and transport techniqueso Providing hardware maintenance for environment supported servers, remote routers,

Systems software, database, middleware and Applications software products and ancillary components as required to operate the systems

o Tracking, managing, communicating and supporting resolution of network exceptions.o Evaluating and testing, in advance, network, hardware, and interface equipment. The

Contractor will configure and install Equipment that will be attached to, and will communicate over, the LAN.

o Supporting protocol conversion and security, as set forth in a Project, this SOW, or the Run Book or other supporting documents.

Develop and provide reports on the status of the LAN as set forth in the Run Book or other supporting documents.

The State will:

Provide all WAN support and the necessary network connectivity up to the Contractor Service Delivery Center demarcation point, as agreed to by the Parties; and

Provide additional WAN capacity for any supported server resource that has reached critical usage levels and is impacting the Contractor’s ability to provide the Services or relieve the Contractor of any affected Service Levels until such time as the required capacity is installed.

Page [89]


8.7 Ongoing Application Responsibilities

8.7.1 Systems Management and AdministrationThe Contractor will:

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

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

Manage the security functions related to the Systems software including administrative access and passwords and the related security controls to maintain the integrity of the Systems software, based on the Contractor’s standard service center security processes.

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

Support the anti-virus solutions for the Intel supported servers and systems managed by the Contractor.

maintain solution delivery elements including but not limited to: software, microcode, patches, Systems software, connectivity software in accordance with the State policies listed in the State policies and have data and configuration currency adequate as to not delay testing effort or overall timing, unless otherwise requested by the State under an approved exception request. The Contractor will reasonably accommodate the State testing, review and approval processes prior to the installation of these elements in the production environment.

Provide management services to support the following infrastructure services and roles:

o Supported server administration, set-up and configurationo Performance tuningo Infrastructure upgradeso Infrastructure capacity planningo Backup and system restore

The State will:

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

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

8.7.2 PeopleSoft Environments and Ancillary Application Technical Support

The Contractor will perform:

Page [90]


PeopleSoft Application Technical Support including:

Maintaining PeopleSoft Application performance, availability and stability of the production applications with the hardware resources.

Understanding the issues related to in-scope PeopleSoft and ancillary Applications requiring analysis of the technical components of the system, including the application, database, system software and hardware.

Conducting post-mortem reviews for corrections to technical issues with in-scope PeopleSoft and ancillary Applications.

PeopleSoft Application Administration Support including:

Monitoring applications, applying patches, and administering the system logs. Performing various technical activities such as code/object migrations, patch implementations,

log administration, various data copies and exports, and general assistance in issue resolution such that migrations into production will be executed at agreed periodic intervals and other production changes will be scheduled during the maintenance window.

Supporting multiple release levels of Applications, as requested by the State.

PeopleSoft Application Preventive Maintenance including:

Performing application tuning, code restructuring, providing tools and other efforts to help improve the efficiency and reliability of applications and to help reduce ongoing maintenance requirements.

Assessing, developing, and recommending opportunities to reduce (or avoid) costs associated with application support and operations.

Making use of best practices and tools to enhance code reusability. Providing appropriate Contractor related data for periodic State analysis and review of

resources deployed for preventive maintenance and planning preventive maintenance. Monitoring and analyzing trends to identify potential issues and following-up on recurring

problems. Maintaining Applications in accordance with the State’s strategies, principles, and standards

relating to technical, data and Applications architectures as communicated to the Contractor. Contributing to the ongoing development of the State’s strategies, principles, and standards

relating to technical, data and Applications architectures through, at a minimum, advising the State of developments in technology which may be applicable to the State business requirements.

Analyzing and recommending to the State methods to improve performance of Applications software. Such analysis and recommendations will include recommending solutions regarding storage management.

Performing: (I) adaptations to PeopleSoft applications software as necessary to maintain the operability and full functionality of such software Element or Module following new releases, enhancements and upgrades (of Systems software or Applications software), and (II) other work

Page [91]


to implement technology changes (e.g., System software upgrades or new scheduling software). Testing new interfaces to Applications when adaptive development work is performed.

8.7.3 PeopleSoft Environment MaintenanceThe Contractor is to be responsible for all unit, system, performance and regression testing, as well as Installation Verification Tests (IVT) for infrastructure and system-related changes. Such changes must not be introduced into a Production environment until they have been through the complete test cycle in Dev/Test.

State personnel are responsible for all final, user-acceptance testing, including system, regression, performance testing, review of results and parallel testing in preparation for go-live.

The Contractor is responsible for monitoring all Third Party software vendors and vendor services for proactive notification of all applicable patches and updates. When new items are released they must be tested by the Contractor in its protected test environments, and scheduled for application during the next scheduled maintenance window. A priority update window may be requested in advance of schedule if a patch or fix is deemed to be critical or security related.

Standard Contractor change control policies and practices will apply, and must follow the migration/test progression from Development to Test to Production.

The State does not require applying individual patches as they are released, unless there is a critical item that must be addressed in an “off-cycle” manner. The State’s required practice is to bundle up patches over the course of a specific period and then schedule those for application to the appropriate system environment per documented change control procedures.

These intervals may vary, but for the State’s HR/Payroll applications, the State prefers that the patch bundles be synched up with the tax release schedule published by PeopleSoft (e.g., 3-4 times per year.) The elapsed time from a tax release to the application of the corresponding bundle is to be scheduled in consultation with the State, and based on mutually agreeable scheduling and availability of end users to test in the respective (Development and Test) database environments.

The Contractor will test modified software prior to any move to production and coordinate with the State for scheduling and execution of end user testing of the service packs and patches. Acceptance testing signoff by the State is required prior to any move to a production environment.

For all PeopleSoft patches, fixes and bundles, the Contractor must perform identification and research (bundling) and apply each of the applicable State environments and validation testing. State end-user personnel are responsible for final acceptance testing (sign-off) in each environment.

These updates are to be applied in conjunction with the Tax/Regulatory release schedule as follows:

PeopleSoft tax/regulatory updates: Identification/research is performed by the Contractor; the updates must be applied by the Contractor to each of the applicable State environments and

Page [92]


validation testing by the Contractor must be performed. State end-user personnel are responsible for final acceptance testing (sign-off) in each environment.

PeopleSoft application releases: Identification/research is performed by the Contractor. The application update schedule is determined by the Contractor and State. Once approved by State, these must be applied by the Contractor to each of the applicable State environments and validation testing by the Contractor must be performed. State end-user personnel are responsible for final acceptance testing (sign-off) in each environment.

PeopleSoft PeopleTools upgrades: Identification/research is performed by the Contractor. The Tools update schedule will be jointly determined by the State and the Contractor. Once approved by the State, these must be applied by the Contractor to each of the applicable State environments and validation testing by the Contractor must be performed. State end-user personnel are responsible acceptance testing (sign-off) in each environment.

3rd Party patches/fixes: application releases and upgrades: This will depend on the specific Third Party application software in question. If the Third Party software is owned and operated by the Contractor (e.g., Mercury, Oracle DBMS), then the identification/research is performed by the Contractor; these must be applied during monthly major maintenance windows by the Contractor to each of the applicable State environments and IVT/regression tested by the Contractor. State end-user personnel may be required to perform some basic acceptance testing (sign-off) in each environment depending on the nature of the change.

Hardware upgrades and Hardware Fixes: For each of these hardware or firmware items, the identification/research is performed by the Contractor; these must be applied during monthly major maintenance windows by the Contractor to each of the applicable State environments and IVT/regression tested by State. State end-user personnel may be required to perform some basic acceptance testing (sign-off) in each environment depending on the nature of the change.

8.7.4 Major and Minor EnhancementsRelease upgrades for packaged software are initiated through periodic releases by the vendor (primarily Oracle/PeopleSoft and other infrastructure elements as described in Section 6, Technical Environment Overview) releases.

The State understands the importance of 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.

The State considers any 8.x.x to 8.x.y upgrade a minor upgrade and any 8.x to 8.x or 8.x to 9.x upgrade (or subsequent versions as available over the term of this Contract) as a major upgrade for its Application and Supporting Infrastructure and Environment. The Contractor must provide all minor and major upgrades as part of the Contractor Managed Service offering at no additional fee (i.e., included in the quoted pricing for this RFP). Technical upgrade services must be included as part of the hosting contract for all minor and major upgrades.

Technical minor and major upgrade services embedded within the Managed Services contract include the technical upgrade execution, customization reapplication support and related help desk support.

Page [93]


All consulting services required to support minor or major upgrades would be scoped and planned in detail at the time the requirement arises and supported within the base Managed Services contract and include any required Project management, functional consulting on-site technical consulting needs associated with upgrade activities which can include activities such as business process analysis, version analysis, operational support, fit/gap analysis, testing, training and other on-site consulting activity.

Major and Minor Upgrades are to be incorporated into the overall Contractor pricing and as a set of requirements, Contractors are to comply with the following:

The State’s requirement is to always operate on a set of Application and Technical Infrastructure components that are on the current support model and terms as provided by the underlying software or Hardware provider (e.g., production PeopleSoft modules must be on Oracle’s then current supported version listing)

As part of annual planning and coincident with monthly governance review meetings, the Contractor is to inform State of any software, hardware or infrastructure components that are moving beyond a current support model and the Contractor’s plan to implement the required updates in a controlled manner to the applicable State environments to maintain compliance with software vendor support models

Based on review of this upgrade 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 Project and authorize the Contractor to perform these upgrade services to maintain a the required support model.

Upgrade planning must factor any regularly scheduled batch processing or system availability as well as any seasonal processing requirements (e.g., end of year W-2 processing, monthly financial closes, etc.) and should be scheduled to maintain compliance with system availability as specified under State SLAs and in consideration of then prevailing Run-Book or production schedule.

The Contractor will lead the assessment of the need for an application enhancement; The Contractor will be responsible for the design, development, and implementation of the

Minor/Major enhancements in the State environments (this includes requirements/design discussions, design review/signoff, document design specification, document and execute unit and integration/interface tests, support business in executing their UAT);

The Contractor must plan and deploy periodic releases of non-emergency patches and enhancements (e.g., test new functionality, regression test entire application, document release notes, coordinate with business for end user change management/communication)

The Contractor must provide technical support services required for enhancement (e.g., tuning the performance, integrating with State technical infrastructure).

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

Minor enhancements are initiated when the State identifies a functional, technical, legal, quality or external requirement that is driving a minor change to the in-scope application(s).

Page [94]


All System Enhancements will be performed in accordance with the appropriate software development lifecycle procedures in Attachment Nine.

Notwithstanding Major and Minor Upgrade enhancement requirements as outlined above, the Contractor has an obligation to maintain all technical elements in keeping with a current support model, the service level requirements as outlined in this RFP, and in accordance with agreed procedures associated with the minimization of exposure to viruses, 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, hardware and ancillary elements of the Managed Service.

8.8 Program Management Services

8.8.1 GeneralThe Contractor will be responsible for managing the overall delivery of the Services to the extent defined and agreed in a Project. The Contractor’s general responsibilities with respect to Project Program Management include the following tasks, activities and responsibilities listed below.

8.8.2 Program ManagementThe Contractor will:

Deliver Projects in a manner that is designed to help minimize disruption to the State business environment.

Balance Project scope, quality, effort, schedule, budget, and resource risks or conflicts jointly with the State.

Develop and report business and technical risk and impact analyses. Conduct post delivery analysis, documenting preferred experiences, and compiling

recommendations for purposes of continuous service improvements. Prepare a proposal upon receipt of a approved request from the State, to include the following:

o A Project Plan.o Delivery cost and resource estimates for each phase of the Project.o Cost estimates for the ongoing maintenance resource and infrastructure requirements

and costs for the solution(s) post-implementation.o Supporting general Project management principles as follows: o Using the State approved Project management tools (currently Microsoft® Project). o Recommending, maintaining and updating a list of the Contractor’s work activities and

Projects.o Developing, maintaining and updating Project schedules.o Monitoring, reporting, and analyzing actual results versus forecasted results including

budget, hours, milestone achievement, estimates to complete, key dependencies, key quality or acceptance gates and any other items the Contractor deems necessary to deliver the Project.

o Holding weekly status update meetings.

Page [95]


o Developing and providing to the State a status report summarized for all Projects. o Establish, review and enhance procedures by which the State may request

enhancements, customizations, interfaces, modifications or other changes to each development Project.

8.8.3 Quality AssuranceThe Contractor will:

Develop and document quality assurance processes and procedures for the delivery of Services. Confirm compliance with agreed-upon quality assurance procedures. Conduct quality and progress reviews with appropriate the State personnel. Systematically document and incorporate preferred experiences from related Projects and

activities into future work. Review Project performance and outcomes relative to documented business and financial

goals/expectations as requested by the State based on mutually agreed business case, Project rationale, goals and objectives and other relevant measures of success based on the State goals.

8.8.4 Service DeskThe Service Desk provides the single point of contact (SPOC) for day-to-day communications between the State key personnel/IT staff and Application Administrators. Requests and incidents are reported by Users to the IT organization through the Service Desk in accordance with the Run Book or other supporting documents provisions. It is the single contact point for the State Users to record their problems and requests related to the supported servers and the Applications on those supported servers. If there is a direct solution then the Service Desk provides immediate resolution, if not then it creates an incident Report. Incidents will initiate the appropriate chain of processes: Incident Management, Problem Management, Change Management, Release Management and Configuration Management. This chain of processes is tracked using a trouble ticketing system, which records the execution of each process, quality control point, and store the associated output documents for traceability. Such processes and procedures will be as set forth in the Run Book or other supporting documents.

General Contractor tasks include:

Handling incidents and requests through full life cycle management of all service requests as set forth in the Run Book or other supporting documents.

Provide a Single Point of Contact for entry and exit to the service process and providing an interface for Third Parties essential to the service processes.

Providing ease of use and a good customer experience for the State Users. Maintaining security and assuring data integrity as required in this SOW. Providing timely and effective communication which keeps the State Users informed of progress

and of appropriate advice on workarounds.

Page [96]


8.8.5 Incident ManagementUnder the ITIL service delivery model requested in the RFP and as appropriate to driving a high quality service, the Contractor will:

Provide the single point of IT contact for User support needs. Track and manage incidents, including by employing procedures for proactive monitoring,

logging, tracking, escalation, review, and reporting (historical and predictive) for incidents, as set forth in the Run Book or other supporting documents.

With the State, implement a process that establishes, to the extent reasonably possible, end-to-end responsibility and ownership of incidents in a manner that helps reduce redundant contacts and helps eliminate the need for the Users to describe the incident multiple times to different Contractor personnel.

Categorize and document the relative importance of each incident according to the severity levels as agreed to by the Parties.

Monitor and manage each incident, including incidents associated with changes, and report on the status of resolution efforts until it is corrected or resolved and an authorized User confirms such resolution, as set forth in the Run Book or other supporting documents.

Assist the State with the prioritization and maintenance of outstanding work logs.

8.8.6 Additional Services To the extent an incident is due to errors or bugs in an in-scope environment, Supported server

or in-scope software element licensed by a Third Party to the State, assist the State by referring such incident to the appropriate Third Party entity for resolution and coordinating with the Third Party contractor as appropriate to help minimize the State role in problem management.

Performing trend analyses at the State request, and no less frequently on a quarterly basis when not otherwise requested, on the volume and nature of incidents in order to identify possible areas for improvement.

Implementing measures to help avoid unnecessary recurrence of incidents, by performing root cause analysis and event correlation.

8.8.7 Service Desk Tools Utilizing Contractor owned or licensed tools, and enhancing processes, to proactively perform

problem management, with the objectives of automating the problem management process. Granting the State access to the problem tracking system via the internet from all facilities

where the Services are performed and where the State has access to the internet, and allowing the State to monitor and view the ticket status on an ongoing basis.

Making Contractor owned or licensed tools available until the completion of Transfer Assistance Services to facilitate knowledge transfer associated with the transfer of service responsibilities.

8.8.8 Asset Inventory and ManagementReporting of Assets, Usage and Operations/Availability

Page [97]


Contractor will provide the State an asset inventory report on a monthly basis. The inventory will consist of the servers, server environments, and summary asset usage statistics, derived from Contractor provided operational system instrumentation and monitoring tools, for all billable assets assigned to an invoice or bill.

In addition to usage statistics the Contractor will provide a set of availability and operational statistics sufficient to validate any charges or credits that arise from compliance with the State and Contractor Service Level Agreements in effect at that time.

8.8.9 Asset Usage Report These availability and operational statistics will be measured by periodic sampling of a

statistically significant portion of the records in the Asset Management System, matching them to the availability and operational metrics in effect for each asset and validating the accuracy of the information in such records regarding asset identification, location, ownership, and chargeback details and include the following at a minimum: Manufacturer Model Serial Number Description Asset tag (if applicable) Processor Type Host Name Memory Total Disk Space Available Disk Space Number of Physical Processors (or virtual processors if applicable) Location: Building, Room, Street address, City, State, Zip Code Systems software such as operating system(s), Virtual Machine software, Operating Versions

of the software and any relevant “edition” or “service pack/revision level” identifiers. Asset Database

In an effort to provide a degree of transparency to the State services, All supported servers assigned for the State use must have an auto-discovery capability installed for the purpose of reporting installed Applications (non-OS). During the migration period, the Contractor is to conduct an initial inventory to ensure the accurate initial population of an Asset Management tracking system during the migration Period and prior to steady-state operations.

Contractor is to provide tagging or loading each physical asset with a bar-code label or similar device for purposes of physical identification, auditing and tracking as well as maintaining and promptly updating the Asset Management tracking system to account for IMACs. Contractor to accommodate the provision of specified the State personnel with read-only access to the asset inventory and Asset Management System as well as the capability to generate periodic reports as necessary or requested by the State. Contractor to respond in a timely manner to queries and requests from the State concerning

Page [98]


inventory data or supporting information for purposes of bill verification, annual audits and other analysis, accounting or financial requirements.

8.8.10 Other IT Management Services Problem Management identifies and resolves the root causes of service disruptions. It includes:

Root Cause Analysis and identification; Submission of Request for Change; Prioritizing resources required for resolution based on business need; and Updating the knowledge base.

General. Contractor responsibilities include:

Analyzing trends and participating in the State continuous improvement process striving to enhance its operations and identifying continuous improvement ideas.

Sharing applicable best practices that may improve the State processes and enabling technologies.

Conducting periodic knowledge exchanges between Contractor team and the State designated individuals.

Assisting with implementing the State defined IT control requirements including updating security matrix spreadsheets, and implementing Supported server and Systems software configurations for access control.

Capacity Planning.

Contractor will:

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 infrastructure needs to correctly plan for capacity – periodic capacity increases as well as burst requirements.

Monitor system use/capacity, forecast capacity and review with the State Infrastructure Management on a quarterly basis.

The State will:

Project future Supported server 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;

Authorize Contractor to purchase additional capacity for any Supported server resource that has reached critical usage levels and is impacting Contractor's ability to provide the Services, at the State expense, or relieve Contractor of any affected Service Levels until such time as the required capacity is installed, or relieve Contractor from the affected Service Level Commitments; and

Page [99]


Review Supported server performance and capacity and throughput for new Applications before promotion into the production environment to resolve any over capacity situations.

Maintaining Support Environment Currency. Contractor’s responsibilities are to maintain Development, Testing, Training and environments in to be at a minimum reflective of then current production State (inclusive of application code, State extensions, configuration data and values, representative data/transactions and user profiles) at a level no less current than three (3) months (Contractor to assume a quarterly total refresh). For testing activities, the currency of the production state maintained in system, performance, user, regression and other required test environments must be aligned with the overall scope of the testing to occur and may require a more up-to-date reflection of then current Production Environment. The working standard for Testing environment currency must be designed as to not preclude any testing efforts, introduce undue delay, and be reflective of the intended Production Environment for final implementation.

The State requires that the Contractor work with the State to ensure appropriate precautions are taken to mask confidential, financial, or otherwise sensitive data when creating the environments from a copy of Production.

Continuous Improvement. Contractor’s responsibilities with respect to continuous improvements will include the following:

Submit improvement ideas, and agree an annual Supported server consolidation target to reduce less physical devices for initially transferred Services (rebalancing, replacement, planned obsolescence, virtualization, re-hosting, decommissioning).

Setting of annual and quarterly aggregate processing capability increases as a Project.

Provisioning. Contractor’s responsibilities with respect to the provisioning Services will include the following:

Virtual machine provisioning. Perform all associated setup, configuration and maintenance per manufacturer or best practices specifications.

Standard configuration physical machines. Set of representative hardware includes: Cabinet (rack, power, UPS) Hardware (CPU/ server supported servers, disk arrays, monitors) Networking equipment (i.e., switches)

8.9 Disaster Recovery & Business ContinuityThe Contractor will have a Disaster Recovery Plan for its Service Delivery Center. The Disaster Recovery Plan will document the sequence of events to follow in the circumstance that an internal or external interruption impacts facility services provided to tenants of the Contractor facilities.

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

Page [100]


The activities of the Disaster Recovery Plan are intended to reduced or minimize downtime of critical equipment, interruption of employee work schedules, and financial exposures for the 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).

Internal failures include but are not limited to chilled water, steam or compressed air systems. External failures include but are not limited to a failure of external utilities such as electricity, natural gas, domestic water or telephone services.

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

8.9.1 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:

Provision for offsite and geographically diverse alternate disaster recovery site that has sufficient computing and network 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 disaster site to occur within 48 hours of failure of primary site Transfer of the State data, configuration and user access to this site is to occur within 48 hours

of failure Restoration of primary operations site operations (once available) within 24 hours Notification of primary site failure within 60 minutes, and intent to migrate to alternate site

within 4 hours of failure Provision of redundant processing hardware to ensure 24X7 operations Provision of redundant power to ensure 24X7 operations Provision of redundant networking (network devices and telecommunications access) to ensure

24X7 operations Provide data center security to help minimize interrupted operations Provide fire detection and suppression capabilities to adhere to service levels contained

elsewhere in this document with regard to systems availability, failover and service levels as agreed.

8.9.2 TestingEstablishing joint test objectives with the State designed to verify that the in-scope Applications will be available within the agreed upon timeframes contained in the mutually agreed disaster and business continuity plan.

Page [101]


Scheduling and testing components of the disaster recovery and business continuity plans relating to the in-scope Applications at least annually in cooperation with the State, its designees, any testing and recovery providers and relevant State Third Party Contractors.

Continuing to operate and manage the Services during periodic disaster recovery tests.

Notifying the State as soon as practicable upon becoming aware of a disaster affecting the Services.

Coordinating with the State to support the mutually agreed disaster recovery and business continuity plan. In such regard, Contractor will:

Perform necessary migrations of the software code and data as required to reinstate the in-scope Applications so that they are functional at a backup location provided by the Contractor in accordance with the procedures set forth in the engagement practices and relevant Statements of Work;

Coordinate with the State to support the reinstatement of the in-scope Applications at such backup location; and

Maintain provision of the Services for unaffected areas.

Following any disaster, at the State’s request Contractor will 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.

Following any disaster, conducting 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.

Provide an annual test, documented results, remediation and feedback procedures contained in the mutually agreed disaster recovery and business continuity plan and allow for State participation and review of the testing process.

8.10 Maintaining Solution and Operations Documentation Contractor will:

Document the solutions developed or modified by the Contractor in accordance with established methods, processes, and procedures such that, at a minimum the State or a competent Third Party service provider can subsequently provide the same scope of Services following the period of Transfer Assistance Services.

Develop and maintain, as agreed appropriate, the documentation on in-scope environments. Where it is determined that documentation is inaccurate (for example, due to demonstrated

Page [102]


errors or obsolescence), and such inaccuracy may negatively affect the Services, Contractor will correct such documentation as part of normal day-to-day operational support.

Update programmer, End User and operational reference materials.

8.11 Mandatory Full Lifecycle SDLC Deliverables and ProcessContractor will provide a disciplined systems development life cycle methodology for use on Application development and maintenance Projects and will adhere to such methodology during the performance of Application development Projects. Contractor will adapt this methodology as required to meet the State’s needs. Contractor will provide the State with a comprehensive description of the methodology, the formal training available if required, the development tools and templates used with the methodology, the Project management tools to be used with the methodology, and the plan for implementing the methodology within the State environment.

8.12 Termination and Termination Assistance Services

8.12.1 OverviewContractor will 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 will 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 Third Party provider (“Successor”). As part of Termination Assistance Services, Contractor will 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 will make such information available to the Successor designated by the State.

Contractor will cooperate with the State in its attempts at transferring the services responsibilities another provider in a manner in keeping with not adversely affect the provision of ongoing services.

8.12.2 ResponsibilitiesCommencing six (6) months prior to expiration of this Contract or on such earlier date as the State may request, or commencing upon a notice of termination or of non-renewal of this Contract, and continuing through the effective date of expiration or, if applicable, of termination of this Contract, Contractor will provide to the State, or at the State’s request to the State’s designee, the termination/expiration assistance requested by the State to allow the Services to continue without interruption or adverse effect and to facilitate the orderly transfer of the Services to the State or its designee (including a competitor of Contractor). Contractor will also provide Termination/Expiration

Page [103]


Assistance in the event of any partial termination of this Contract (e.g., termination of an element or other component of the Services) by the State, such assistance to commence upon the State’s notice of termination to Contractor. Termination/Expiration Assistance will include the assistance described in the following:

The State or its designee will be permitted to undertake, without interference from Contractor, to hire any Contractor Personnel primarily performing the Services as of the date of notice of termination, or, in the case of expiration, within the six (6) month period (or longer period requested by the State) prior to expiration. Contractor will waive, and will cause its subcontractors to waive, their rights, if any, under contracts with such personnel restricting the ability of such personnel to be recruited or hired by the State or the State’s designee. The State or its designee will have access to such personnel for interviews and recruitment.

If the State is entitled pursuant to this Contract to a sublicense or other right to Use any software owned or licensed by Contractor, Contractor will provide such sublicense or other right.

At the State's request, Contractor will (A) obtain any required consents from Third Parties and thereafter assign to the State or its designee leases for some or all of the equipment that was necessary as of the date of termination/expiration of this Contract primarily for providing the Services, and the State will assume the obligations under such leases that relate to periods after such date; and (B) sell to the State or its designee, at the lower of Contractor's then current book value, unrecovered capital payments or fair market value, some or all of the equipment owned by Contractor that was necessary as of the date of termination/expiration of this Contract primarily for providing the Services. Contractor will also provide all users and other documentation relevant to such equipment which is in Contractor's possession. The State will assume responsibility under any maintenance agreements for such equipment to the extent such responsibilities relate to periods after the date of termination/expiration of this Contract.

Contractor will obtain any necessary rights and thereafter make available to the State or its designee, pursuant to agreed terms and conditions, any Third Party services then being utilized by Contractor in the performance of the Services, including services being provided through Third Party service or maintenance contracts on equipment and software used to provide the services. Contractor will be entitled to retain the right to utilize any such Third Party services in connection with the performance of services for any other Contractor customer.

For a period of up to twelve (12) months following the effective date of termination/expiration under other provisions of this Contract, at the State's request Contractor will continue to provide Termination/Expiration Assistance. Actions by Contractor under this section will be subject to the other provisions of this Contract.

In the process of evaluating whether to undertake or allow termination/ expiration or renewal of this Contract, the State may consider obtaining, or determine to obtain, provisions for performance of services similar to the Services following termination/ expiration of this Contract or to return these services to the State for ongoing operation. As and when reasonably requested by the State for use in such a process, Contractor will provide to the State such

Page [104]


information and other cooperation regarding performance of the Services as would be reasonably necessary for the State or a Third Party to prepare an informed option analysis for such services, and for the State or a Third Party not to be disadvantaged compared to Contractor if Contractor were to be invited by the State to submit a proposal.

Contractor acknowledges that, in the event it breaches (or attempts or threatens to breach) its obligation to provide Termination/Expiration Assistance as provided in this section, the State will be irreparably harmed. In such a circumstance, the State may proceed directly to court. If a court of competent jurisdiction should find that Contractor has breached (or attempted or threatened to breach) any such obligations, Contractor agrees that, without any additional findings of irreparable injury or other conditions to injunctive relief (including the posting of bond), it will not oppose the entry of an appropriate order compelling performance by Contractor and restraining it from any further breaches (or attempted or threatened breaches).

Page [105]


Contractor will provide State an inventory of resources (or resource full time equivalents) then performing work under the Managed Services statement of work to assist the State in determining the appropriate resourcing and skill model required for the State or a State contracted Third Party to assume the services as provided by the Contractor at the time of termination. This resource inventory will include (at a minimum); full-or part time equivalent resource models; skill and experience levels; education or technical skill certification levels required; and other mutually agreeable and pertinent information for the State to assemble or source the capabilities to perform the work described herein upon termination of the Contract post transition of services. Contractors are to note State does not require names of individuals as part of fulfilling this requirement.

**In addition to the requirements in this section, in the event of a transfer of services back to the State and at the State’s sole discretion, Contractor will design and implement a training program to State employees designed to convey operational and technical knowledge associated with the ongoing operation of the in-scope applications and systems, conduct knowledge and documentation transfers for the then current operational processes and tasks and work to ensure an overall continuity of services until such time as State employees can reasonably perform the roles in keeping with service levels and other operational quality, timeliness and accuracy considerations associated with the delivery of the service. These services will be priced utilizing the then current Contractor rate card at the time of the request and as approved by the State.**

8.12.3 StandardsThe terminated or expired Services are 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 Third Party IT-related costs incurred by the State in transferring the Terminated Services are acceptable to the State under the circumstances.

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

Any disruption or deterioration of the remaining Services following the transfer (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 in the Governance Section 7.0 will continue to apply during the agreed Termination Assistance Period.

8.12.4 Termination Assistance PlanThe contents of Termination Assistance Plan will include, unless otherwise agreed, the services, functions, and activities as defined below:

RFP Amendment Replacement Page Issued on 11/06/08Page [106]


Documentation of existing and planned Projects and support activities. Identification of the Services and related positions or functions that require transition and a

schedule, plan and procedures for the State or its designee assuming or reassuming responsibility.

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. Description in detail of any dependencies on the successors necessary for Contractor to perform

the Termination Assistance Services (including an estimate of the specific Contractor staffing required).

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.

8.12.5 Termination Management TeamContractor will provide a senior Project manager who will be responsible for Contractor’s overall performance of the Termination Assistance Services and who will be the primary point of contact for the State in respect of the Termination Assistance Services during the Termination Assistance Period.

The State will appoint a senior Project manager who will be the primary point of contact for Contractor during the Termination Assistance Period. Additionally, the State may appoint a Transformation Team that would be responsible for the review of then current services provided by the Contractor and work to facilitate an orderly transition of services.

8.12.6 Operational TransferContractor will perform the activities reasonably required to help effect a smooth and orderly transfer of operational responsibility for the Terminated Services.

Facilitating access to the State source code, object code, object and production libraries, reference files, field descriptions, record layouts and technical specifications along with run documentation for the State software then in Contractor’s possession including tools, scripts, run books, production schedules and procedures as required to support the in-scope Applications which may be used in training, knowledge transfer, sizing assessments, operational reviews and other uses required by the state at the time of Transfer.

Cooperating with the Successors in conducting migration testing.



Providing the State owned documents and information related to the functionality, program code, data model and data base structure, and access methods for the in-scope Applications and manual and automated processes used for the State, within the possession or control of Contractor, and reviewing such processes, documents and information with the Successor as reasonably requested.

Cooperating with the State’s test plans, back out procedures, and contingency plans as part of the migration of Terminated Services.

After the transfer of the provision of Terminated Services to the State, its designee(s), or both, providing additional assistance as reasonably requested by the State to facilitate continuity of operations, through the end of the Termination Assistance Period.

8.13 Additional Managed Services Terms and ConditionsThe following provisions are applicable to this Managed Services SOW and supplement, but do not replace the provisions contained in Attachment Four. The provisions in Attachment Four continue in full force and effect for this Managed Services SOW and all other provisions of the Contract.

8.13.1 Audit

(a) Onsite Operational and Financial Examinations. To assist the State in its activities related to oversight of Contractor in the performance of the Contract, in addition to the examinations that occurred prior to the execution of this Contract, subsequent to the Effective Date of this Contract, the State, or its agent, may conduct onsite operational and financial examinations of Contractor.

(i) The onsite examinations may include, without limitation, verification that business is conducted as represented by Contractor at all sites where it performs Managed Services or Disaster Recovery for the State; Contractor’s facilities are adequate to support claims of staffing, services performed and inventory housed; and the facilities provide adequate security for staff, functions performed and services rendered. This examination may include verification that Contractor has adequate information security compliance policies and procedures.

(ii) The financial examination may include, without limitation, a review of Contractor’s current balance sheet; its most recent annual report; up to three (3) years of third party audits; tax returns for the previous three (3) years; and all documentation supporting employee bonds and insurance policies of Contractor.

(b) Consent to Examinations.

(i) By execution of this Contract, Contractor consents to the examinations described in these provisions and consents to such examinations being conducted by the State or its agent.

(ii) The State may conduct such examinations from time to time during the Term of this Agreement and the consent to the examinations provided by Contractor shall be a continuing



consent to conduct the examinations periodically in the State’s discretion during the Term of this Contract.

(c) Right to Terminate.

(i) In the event the State determines in its sole discretion that the results of any examination of Contractor is unsatisfactory per the requirements of the Contract and not remedied within a 30 day period following notice from the State, the State may terminate this Agreement, in part or in full.

(ii) If the Contractor fails to satisfy the requirements of the State with regard to security of information, or if an examination reveals information that would result in a continuing contractual relationship that causes the State to be in violation of any law, the State may terminate this Contract immediately without notice.

(iii) If Contractor fails to satisfy the requirements of the State with regard to matters not related to those discussed in paragraph (c) (i) or (ii), the State will provide Contractor with notice and an opportunity to cure the failure within thirty (30) days. If the failure is not cured by Contractor within such thirty (30) day period, the State may terminate this Contract without further notice.

8.13.2 Criminal Background Check of PersonnelContractor agrees that (1) it will conduct third-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 (“Sensitive Services”). 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.

8.13.3 ConfidentialityA. Protection of State Data. To protect State Data as described in this Managed Services SOW, in addition to its other duties regarding State Data, Contractor shall:

1. Maintain in confidence any personally identifiable information (“PI”) it may obtain, maintain, process, or otherwise receive from or through the State in the course of the Agreement;



2. Use and permit its employees, officers, agents, and independent contractors to use any PI received from the State solely for those purposes expressly contemplated by the Agreement;

3. Not sell, rent, lease or disclose, or permit its employees, officers, agents, and independent contractors to sell, rent, lease, or disclose, any such PI to any third party, except as permitted under this Agreement or required by applicable law, regulation, or court order;

4. Take all commercially reasonable steps to (a) protect the confidentiality of PI received from the State and (b) establish and maintain physical, technical and administrative safeguards to prevent unauthorized access by third parties to PI received by Contractor from the State;

5. Give access to PI of the State only to those individual employees, officers, agents, and independent contractors who reasonably require access to such information in connection with the performance of Contractor’s obligations under this Agreement;

6. Upon request by the State, promptly destroy or return to the State in a format designated by the State all PI received from the State;

7. Cooperate with any attempt by the State to monitor Contractor’s compliance with the foregoing obligations as reasonably requested by the State from time to time. The State shall be responsible for all costs incurred by Contractor for compliance with this provision of this subsection;

8. Establish and maintain data security policies and procedures designed to ensure the following:

a) Security and confidentiality of PI;b) Protection against anticipated threats or hazards to the security or

integrity of PI; andc) Protection against the unauthorized access or use of PI.

B. Disclosure to Third Parties. This Agreement shall not be deemed to prohibit disclosures:

1. Required by applicable law, regulation, court order or subpoena; provided that, if the Contractor or any of its representatives are ordered or requested to disclose any information provided by the State, whether PI or otherwise, pursuant to court or administrative order, subpoena, summons, or other legal process, Contractor will promptly notify the State (unless prohibited from doing so by law, rule, regulation or court order) in order that the State may have the opportunity to seek a protective order or take other appropriate action. Contractor will also cooperate in the State’s efforts to obtain a protective order or other reasonable assurance that confidential treatment will be accorded the information provided by the State. If, in the absence of a protective order, Contractor is compelled as a matter of law to disclose the information provided by the State, Contractor may disclose to the party compelling disclosure only the part of such information as is required by law to be disclosed (in which case, prior to such disclosure, Contractor will advise and consult with the State and its counsel as to such disclosure and the nature of wording of such disclosure) and Contractor will use commercially reasonable efforts to obtain confidential treatment therefore;

2. To auditors or regulators;3. To service providers and agents of either party as permitted by law, provided that such service

providers and agents are subject to binding confidentiality obligations; or4. To the professional advisors of either party, provided that such advisors are obligated to

maintain the confidentiality of the information they receive.

C. Limited Use; Survival of Obligations. Contractor may use PI only as necessary for Contractor’s performance under or pursuant to rights granted in this Agreement and for no other purpose.



Contractor’s limited right to use PI expires upon expiration or termination of this Agreement for any reason. Contractor’s obligations of confidentiality and non-disclosure survive termination or expiration for any reason of this Agreement.

D. Disposal of PI. Upon expiration of Contractor’s limited right to use PI, Contractor must return all physical embodiments to the State or, with the State’s permission; Contractor may destroy PI. Upon the State’s request, Contractor shall provide written certification to the State that Contractor has returned, or destroyed, all such PI in Contractor’s possession.

E. Remedies. If Contractor or any of its representatives or agents breaches the covenants set forth in these provisions, irreparable injury may result to the State or third parties entrusting PI to the State. Therefore, the State’s remedies at law may be inadequate and the State shall be entitled to seek an injunction to restrain any continuing breach. Notwithstanding any limitation on Contractor’s liability, the State shall further be entitled to any other rights or remedies that it may have in law or in equity.

F. Disclosure Notification. If Contractor determines that there is any actual or suspected theft of, accidental disclosure of, loss of, or inability to account for any PI by Contractor or any of its subcontractors (collectively “Disclosure”) and/or any unauthorized intrusions into Contractor’s or any of its subcontractor’s facilities or secure systems (collectively “Intrusion”), Contractor must immediately:

1. Notify the State within 24 hours of the Contractor becoming aware of the unauthorized disclosure;

2. Fully cooperate with the State in estimating the effect of the Disclosure or Intrusion’s effect on the State and fully cooperate to mitigate the consequences of the Disclosure or Intrusion;

3. Specify corrective action to be taken; 4. Investigate and determine if an Intrusion and/or Disclosure has occurred; and5. Take corrective action to prevent further Disclosure and/or Intrusion.

Contractor must, as soon as is reasonably practicable, make a report to the State including details of the Disclosure and/or Intrusion and the corrective action Contractor has taken to prevent further Disclosure and/or Intrusion. Contractor must, in the case of a Disclosure cooperate fully with the State to notify the effected persons as to the fact of and the circumstances of the Disclosure of the PI. Additionally, Contractor must cooperate fully with all government regulatory agencies and/or law enforcement agencies having jurisdiction to investigate a Disclosure and/or any known or suspected criminal activity.

8.13.4 Suspension and TerminationNotwithstanding anything in the Contract to the contrary, any time the State has the right to terminate the Contract, the State may elect to terminate the Contract only in part by notifying the Contractor of such decision. By electing to terminate only part of the Contract, the State does not give up its rights to later terminate other portions or the entire Contract. In the event the State terminates all or part of the Managed Services provided by the Contractor, the Contractor shall continue to be obligated to perform the services, both those that are to remain and those that are being terminated, in accordance with the requirements of the Contract, including without limitation, the service level requirements as long as the services continue to be provided. In addition, regardless of whether the termination is for all Managed



Services or only part of the Managed Services, Contractor shall provide the transition services as set forth in this RFP as necessary to enable the State to convert the Managed Services being terminated to another provider, including the State.

8.13.5 Telephone NumbersUpon the termination of the Contract with respect to the Managed Services, any telephone numbers utilized in the performance of the Managed Services shall be transferred to the State. It shall be the responsibility of the Contractor to complete the transfer of the telephone numbers immediately upon the date the Managed Services are terminated. The telephone numbers shall be transferred to the State at no cost to the State. The telephone numbers that shall be transferred are those that the State transferred to the Contractor at the commencement of the Managed Services and all those telephone numbers acquired by the Contractor during the term of the Contract to enable the Contractor to perform its duties and obligations under the SOW for Managed Services.

8.13.6 InsuranceThe Contractor shall provide to the State prior to commencement of the work following the award of the Contract, property insurance coverage to cover casualty loss of State's equipment in Contractor’s possession up to replacement value of equipment. State shall be included on the CGL insurance policies obtained by Contractor as "Additional Insured". Such policies shall cover this Contract with respect to State's status as "Additional Insured" by way of a blanket additional insured endorsement and shall not specifically reference State by name. The provisions of this section shall not be deemed to limit or expand the liability of Contractor hereunder, or limit any rights that State may have including, without limitation, rights of indemnity or contribution. After insurance company determination to repair or replace, the proceeds, if any, from such property insurance based on loss or damage to the State’s equipment will be applied to repair or replacement of that equipment, at the State’s option.

8.13.7 Handling the State’s DataThe Contractor must use due diligence to ensure computer and telecommunications systems and services involved in storing, using, or transmitting State Data are secure and to protect that data from unauthorized disclosure, modification, or destruction. “State Data” includes all data and information created by, created for, or related to the activities of the State and any information from, to, or related to all persons that conduct business or personal activities with the State. To accomplish this, the Contractor must adhere to the following principles:

1. Apply appropriate risk management techniques to balance the need for security measures against the sensitivity of the State Data.

2. Ensure that its internal security policies, plans, and procedures address the basic security elements of confidentiality, integrity, and availability.

3. Maintain plans and policies that include methods to protect against security and integrity threats and vulnerabilities, as well as and detect and respond to those threats and vulnerabilities.

4. Maintain appropriate identification and authentication process for information systems and services associated with State Data.



5. Maintain appropriate access control and authorization policies, plans, and procedures to protect system assets and other information resources associated with State Data.

6. Implement and manage security audit logging on information systems, including computers and network devices.

The Contractor must maintain a robust boundary security capacity that incorporates generally recognized system hardening techniques. This includes determining which ports and services are required to support access to systems that hold State Data, limiting access to only these points, and disable all others. To do this, the Contractor must use assets and techniques such as properly configured firewalls, a demilitarized zone for handling public traffic, host-to-host management, Internet protocol specification for source and destination, strong authentication, encryption, packet filtering, activity logging, and implementation of system security fixes and patches as they become available. The Contractor must use two-factor authentication to limit access to systems that contain particularly sensitive State Data, such as personally identifiable data.

Unless the State instructs the Contractor otherwise in writing, the Contractor must assume all State Data and information is both confidential and critical for State operations, and the Contractor’s security policies, plans, and procedure for the handling, storage, backup, access, and, if appropriate, destruction of that data must be commensurate to this level of sensitivity. As part of the Contractor’s protection and control of access to and use of State Data, the Contractor must employ appropriate intrusion and attack prevention and detection capabilities. Those capabilities must track unauthorized access and attempts to access the State’s Data, as well as attacks on the Contractor’s infrastructure associated with the State’s data. Further, the Contractor must monitor and appropriately address information from its system tools used to prevent and detect unauthorized access to and attacks on the infrastructure associated with the State’s Data.

The Contractor must use appropriate measures to ensure that State Data is secure before transferring control of any systems or media on which State Data is stored. The method of securing the State Data must be appropriate to the situation and may include erasure, destruction, or encryption of the State Data before transfer of control. The transfer of any such system or media must be reasonably necessary for the performance of the Contractor’s obligations under this Contract.

The Contractor must have a business continuity plan in place that the Contractor tests and updates at least annually. The plan must address procedures for response to emergencies and other business interruptions. Part of the plan must address backing up and storing data at a location sufficiently remote from the facilities at which the Contractor maintains the State’s Data in case of loss of that data at the primary site. The plan also must address the rapid restoration, relocation, or replacement of resources associated with the State’s Data in the case of a disaster or other business interruption. The Contractor’s business continuity plan must address short- and long-term restoration, relocation, or replacement of resources that will ensure the smooth continuation of operations related to the State’s Data. Such resources may include, among others, communications, supplies, transportation, space, power and environmental controls, documentation, people, data, software, and hardware. The Contractor also must provide for reviewing, testing, and adjusting the plan on an annual basis.



The Contractor may not allow the State’s Data to be loaded onto portable computing devices or portable storage components or media unless necessary to perform its obligations under this Contract properly. Even then, the Contractor may permit such only if adequate security measures are in place to ensure the integrity and security of the State Data. Those measures must include a policy on physical security for such devices to minimize the risks of theft and unauthorized access that includes a prohibition against viewing sensitive or confidential data in public or common areas. At a minimum, portable computing devices must have anti-virus software, personal firewalls, and system password protection. In addition, the State’s Data must be encrypted when stored on any portable computing or storage device or media or when transmitted from them across any data network. The Contractor also must maintain an accurate inventory of all such devices and the individuals to whom they are assigned.

Any encryption requirement identified in this provision means encryption that complies with National Institute of Standards Federal Information Processing Standard 140-2 as demonstrated by a valid FIPS certificate number. Any sensitive State Data transmitted over a network, or taken off site via removable media must be encrypted pursuant to the State’s Data encryption standard ITS-SEC-01 Data Encryption and Cryptography.

The Contractor must have reporting requirements for lost or stolen portable computing devices authorized for use with State Data and must report any loss or theft of such to the State in writing as quickly as reasonably possible. The Contractor also must maintain an incident response capability for all security breaches involving State Data whether involving mobile devices or media or not. The Contractor must detail this capability in a written policy that defines procedures for how the Contractor will detect, evaluate, and respond to adverse events that may indicate a breach or attempt to attack or access State Data or the infrastructure associated with State Data.

In case of an actual security breach that may have compromised State Data, the Contractor must notify the State in writing of the breach within 2 hours of the Contractor becoming aware of the breach and fully cooperate with the State to mitigate the consequences of such a breach. This includes any use or disclosure of the State data that is inconsistent with the terms of this Contract and of which the Contractor becomes aware, including but not limited to, any discovery of a use or disclosure that is not consistent with this Contract by an employee, agent, or subcontractor of the Contractor.

The Contractor must give the State full access to the details of the breach and assist the State in making any notifications to potentially affected people and organizations that the State deems are necessary or appropriate. The Contractor must document all such incidents, including its response to them, and make that documentation available to the State on request. In addition to any other liability under this Contract related to the Contractor’s improper disclosure of State data, and regardless of any limitation on liability of any kind in this Contract, the Contractor will be responsible for acquiring one year’s identity theft protection service on behalf of any individual or entity whose personally identifiable information is compromised while it is in the Contractor’s possession. Such identity theft protection must provide coverage for all three major credit reporting agencies and provide immediate notice through phone or email of attempts to access the individuals' credit history through those services."



To the extent the State requires the Contractor to adhere to specific processes or procedures in addition to those set forth above in order for the Contractor to comply with the managed services principles enumerated herein, those processes or procedures are set forth in this Managed Services SOW.



9 Managed Services Service Level Requirements

9.1 Service Level FrameworkThis section sets forth the functional and technical specifications for the Service Level Agreements (SLA) and Service Level Objectives (SLO) to be established between Contractor and the State. This section contains the tables and descriptions that provide the State framework and expectations relating to service level commitments, and the implications of meeting versus failing to meet the requirements and objectives, as applicable. This document defines the State detailed performance, management, and reporting requirements for all Contractor Service Delivery Center Services.

Both the State and Contractor recognize and agree that new categories of Service Levels and Performance Specifications may be added during the term of the Contract as business, organizational objectives and technological changes permit and require.

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

Contractor will be required to comply with the following performance management and reporting mechanisms for all Services within the scope of Managed Services SOW, Section 8, procured by the State:

Service Level Specific Performance – Agreed upon specific Service Level Agreements to measure the performance of specific Services or Service Elements. The individual Service Level Agreements are linked to Performance Credits to incent Contractor performance

Overall Contract Performance – An overall performance score of Contractor across all Service Levels (i.e., SLA and SLO). The overall performance score is linked to governance and escalation processes as needed to initiate corrective actions and remedial processes

9.2 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 SLA GYR State falls in the “Yellow “or “Red” State. The amount of the Performance Credit for each SLA will be based on the Individual SLA GYR State. Further, the amounts of the Performance Credits will, in certain cases, increase where they are imposed in consecutive months. No Service Level Performance Credit will be payable for Contractor’s failure to meet a Service Level Objective.

Set forth below is a table summarizing the monthly Performance Credits for each SLA. All amounts set forth below that are contained in a row pertaining to the “Yellow” or “Red” GYR State, represent

Page [116]


Performance Credit amounts. Except as explicitly stated in the Consecutive Months Credit table below, where a larger percentage may be at risk, Contractor agrees that in each month of the Agreement, up to 12% of the monthly recurring charges (MRC) associated with the Managed Services portion of this RFP (“Fees at Risk”). The Fees at Risk will pertain to failure to meet the Service Levels set forth in the Agreement. Contractor will not be required to provide Performance Credits for multiple Performance Specifications for the same event, with the highest Performance Credit available to the State for that particular event to be applicable.

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 Contractor, unless the State requests a payment in cash.

Moreover, in the event of consecutive failures to meet the Service Levels, the Contractor will be required to pay the State the maximum Credit under the terms of this document.

Contractor will not be liable for any 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 Contractor takes all steps to minimize the effect of such circumstances and to resume its performance of the Services in accordance with the SLAs as soon as possible.

Consecutive Months Credit Table(SLA Performance Credits)

Individual SLGYR State

1st Month

2nd Month

3rd Month

4th Month

5th Month

6th Month

7th Month

8th Month

9th Month

10th Month

11th Month

12th Month

RedA

=1.71% of MRC

A + 50% of A

A + 100% of

A

A + 150% of

A

A + 200% of

A

A + 250% of

A

A + 300% of

A

A + 350% of

A

A + 400% of

A

A + 450% of

A

A + 500% of

A

A + 550% of

A

YellowB =

0.855% of MRC

B + 50% of B

B + 100% of

B

B + 150% of

B

B + 200% of

B

B + 250% of

B

B + 300% of

B

B + 350% of

B

B + 400% of

B

B + 450% of

B

B + 500% of

B

B + 550% of

BGreen None None None None None None None None None None None None

For example, if an Individual SL GYR State is Yellow in the first Measurement Period, Red in the second Measurement Period and back to Yellow in the third Measurement Period for an SLA then the Performance Credit due to the State will be the sum of Yellow Month 1 (B) for the first Measurement Period, Red Month 2 (A + 50% of A) for the second Measurement period, and Yellow Month 3 (B + 100% of B) for the third Measurement period, provided (1) such Performance Credit does not exceed 12% of the aggregate Monthly Recurring Charge (the At-Risk Amount); and, (2) no single Service Level Credit will exceed 20% of the total At-Risk Amount, as stated below:

Service Level Credit payable to the State = (B) + (A + 50% A) + (B + 100% B), based on an illustrative Monthly Recurring Charge of $290,000;

Page [117]


SLA Calculation EXAMPLEMonthly Recurring Charge (MRC) = $290,000.00

Monthly At Risk Amount = 12% of MRC = $34,800Maximum for any one SLA = 20% of At Risk Amount = $6,960

GYR State 1st Month 2nd Month 3rd Month

Red 0 $ 0 $ 7,438.50 0

Yellow 1 $ 2,479.50 1 1 $ 4,959.00

Green 6 $ 6 6

Totals 7 $ 2,479.50 7 $ 7,438.50 7 $ 4,959.00

Adjusted Totals by At Risk Amount and 20% per individual SLA Limitations

(Is monthly total of all Service Level Credits equal to or less than $34,800?) - Yes

(Is monthly amount for any one Service Level Credit equal to or less than $ 6,960?) - Yes

$ 2,479.50


(Is monthly amount for any one Service Level Credit equal to or less than $ 6,960?) - No

$ 6,960.00



$ 4,959.00

Total Quarterly Credit: $ 2,479.50 + $ 6,960.00 + $ 4,959.00

Total Quarterly Credit: $ 14,398.50

The total of any weighting factors may not exceed 100% of the total At-Risk Amount.

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

Service Levels will not apply during the Transition period, but will commence with the Contractor’s assumption of services in the production Steady State environment for all migrated elements in part or in full.

9.2.1 Treatment of Federal, State, and Local Fines Related to Service DisruptionAbove and beyond the Service Levels discussed above, should any failure to deliver services by the Contractor result in a mandated regulatory fine associated with late, incomplete, or incorrect filings as a direct result of Contractor’s inability to deliver services under the defined Statement(s) of Work, production schedules, reporting and filing obligations, the requirements and Service Levels contained herein , the Contractor will be obligated to issue a credit to the State equal to the amount of the fine.

Page [118]


9.3 Overall Contract PerformanceIn addition to the service specific performance credits, on a monthly basis, an overall SL score (the “Overall SL Score”) will be determined, by assigning points to each SL based on its Individual SL GYR State. The matrix set forth below describes the methodology for computing the Overall SL Score:

Individual SLAs and SLOs GYR State

Performance Multiple

Green 0Yellow 1Red 4

The Overall SL score is calculated by multiplying the number of SLAs and SLOs in each GYR State by the Performance Multiples above. For example, if all SLAs and SLOs are Green except for two SLAs in a Red GYR State, the Overall SL Score would be the equivalent of 8 (4 x 2 Red SLAs).

Based on the Overall SL Score thresholds value exceeding a threshold of 26 then executive escalation procedures as agreed to by the parties will be initiated to restore acceptable Service Levels. The State may terminate the Contract for cause if:

a) The overall SL score reaches a threshold level of 52 per month over a period of 3 consecutive months (equivalent to 50% of the service levels in a red State); or

b) Contractor fails to cure the affected Service Levels within 60 calendar days of receipt of the State written notice of intent to terminate; or

c) The State exercises its right to terminate for exceeding the threshold level of 120 per month within five calendar days of receipt of Contractor’s third monthly SLA status report.

Should the State terminate the Contract for exceeding the threshold level of 120 per month, it will pay to Contractor actual and agreed wind down expenses only, and no other Termination Charges.

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

The Services provided under this Scope of Work as of the Effective Date envision the potential of using all new hardware installed at Contractor’s Service Delivery Center, and do not include a substantial transfer of existing the State hardware for production usage. The State retains the right to terminate for Overall Contract Performance under the terms of this Contract will apply only to this Scope of Work.

9.4 Monthly Service Level ReportOn a the State accounting monthly basis, Contractor will provide a written report to the State which includes the following information (the “Monthly Service Level Report”): (i) Contractor’ 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

Page [119]


Performance Credit balance (i.e., credits owed the State by the Contractor) for each Service Level and all the Service Levels (i.e., SLO and SLA results to date); (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) accounting day of the following month.

9.5 Service Level Review and Continual Improvement

9.5.1 Service Levels Review Initial Review: Within six months of the Service Commencement Date or completion of Transition as outlined in the SOW, whichever is sooner, the Parties will meet to review the initial Service Levels and Contractor’s performance and discuss possible modifications to the Service Levels. Any changes to the Service Levels will be only as agreed upon in writing by the Parties.

Initial Six Month Review: Within six months of the Service Commencement Date or completion of Transition as outlined in the SOW, the Parties will meet to review the Service Levels and Contractor’s performance in the period of time since the prior review.

9.5.2 Continuous ImprovementContinual Improvement: Twelve months after the completion of Transition as outlined in the SOW, the Parties will meet to review the Service Levels and Contractor’s performance in the period of time since the prior review. For each SLA and SLO, the performance during the six highest performing months will be averaged and this performance, if in consideration of the prevailing charges, actual delivered service levels if higher than the current SLA/SLO, State may opt for SLA/SLO modification and or a reduced fee structure associated with a lower, but agreeable level going forward.

Ongoing Annual Reviews: Contractor and the State will set a mutually agreed date to conduct annual reviews of the Service Levels and Contractor’s performance with respect to the Service Levels. At a minimum, the annual review will include:

a) Comprehensive review of the previous year’s performance including fault, impact time and duration and a root cause analysis;

b) Compendium of remedial actions, operational or process enhancements, system hardware or software enhancements implemented to address any deficiencies with regard to delivering the Service Levels; and

c) Revision of the Service Levels, if any, based upon mutual written agreement.

9.6 Service Level CommitmentsContractor will meet the Service Level Commitment for each Service Level set forth in the charts below and described in detail in Section 9.7:

Page [120]


Service Level

The State Requirements

SLA or SLO

Support Hours

Required

Response ResolutionIncident Resolution – Mean Time to Repair (Priority 1 Outages)

SLA 7x24 Every 15 minutes until resolution <= 4 hours

Incident Resolution – Mean Time to Repair (Priority 2 Outages)

SLA 7x24 Every 30 minutes until resolution <= 8 hours

Incident Resolution – Mean Time to Repair (Priority 3 Outages)

SLA 7x24 Every 4 hours until resolution <=24 hours

Service Availability – Application Availability SLA 7x24 See specification below -

System Performance & Responsiveness SLA 7x24 See specification below -

Incident Resolution - Issue Triage, Closure and Recidivist Rate

SLO 7x24 See specification below -

Capacity Monitoring & Planning – Capacity Utilization Flag

SLA 7x24 See specification below -

Data Back-up & Restoration – Back-up Success Rate

SLO 8x16 Verify 25% of backup data against original production image per backup session in the schedule

Reschedule backup of entire environment as a preventative measure using new tape stock and backup equipment

Data Back-up & Restoration – Restoration Time

SLA 7x24 See specification below -

Scheduled Provisioning – Virtual Machines SLO 5x9 See specification below <= 8 hours following authorized request

Scheduled Provisioning – Physical Machines SLO 5x9 See specification below <-24 hours following receipt of hardware

User Interaction - Completion of User Deletes

SLO 5x9 - Emergency deletes <= 1 business hourScheduled deletes <= 4 business hours

User Interaction - Completion of User Adds & Changes

SLO 5x9 - <= 1 business day

Security – Security Compliance SLO 7x24 Continuous See specification below

Security – Annual Security Review SLO annual - See specification below

Monitoring & Auditing – Security Breach Detection

SLA 7x24 - See specification below

SLA Reporting Timeliness SLA monthly - See specification below

Billing - Billing Content, Timeliness & Accuracy

SLO monthly - See specification below

Continuous Improvement SLO monthly - See specification below

Asset Management & Refresh – Asset Inventory Element Accuracy

SLA monthly - See specification below

Monitoring and Usage Report SLO 7x24 - See specification below

Operational Process Control & Repeatability – Changes to Production environments

SLO 7x24 - See specification below

Service Availability – Batch Processing SLA 7x24 - See specification below

Service Quality – System Changes SLO 7x9 - See specification below

Page [121]


Service Level

The State Requirements

Service Timeliness – System Changes SLA 7x9 - See specification below

Service Quality & Timeliness – Delivery Date Compliance

SLO 7x24 - See specification below

Page [122]


9.7 Service Levels – User Experience

9.7.1 Incident Resolution – Mean Time to Repair (Priority 1 Outages)

9.7.1.1 Service Level Agreement

Specification: Incident Resolution – Mean Time to Repair (Priority 1 Outages)

Definition: Mean Time to Repair (Priority 1 Outages) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Priority 1 Outage Service Requests for in-scope Services in the Contract Month. “Time to Repair” is measured from time Service Request is received at the Level 2 Service Desk to point in time when the incident is resolved or workaround is in place and the Contractor submits the resolved Service Request to the State for confirmation of resolution.

“Priority 1 Outage Service Request” means an incident where the State’s production use of a solution service has stopped or is so severely impacted that the State personnel cannot reasonably continue to work.

This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan. The initial service level shown for this SLA will be 99.0%, and will be validated during a measurement period. Following the measurement period, the initial Service Level will be adjusted to 99.5%. The measurement period will be as mutually agreed by the Parties, not to exceed six months.

Formula:Mean Time to Repair (Priority 1 Outages)

=

(Total elapsed time it takes to repair Priority 1 Outage Service Requests)

(Total Priority 1 Outage Service Requests)

Measurement Period:

Accounting Month

Data Source: Monthly Service Report

Frequency of Collection:

Per incident

9.7.1.2 Service Level MeasuresIndividual SL

GYR StateIncident Resolution – Mean Time to Repair (Priority 1

Outages).Green <= 4 hoursYellow > 4 hours and <= 6 hours

Red > 6 hours

Page [123]



9.7.2.1 Service Level AgreementSpecification: Incident Resolution – Mean Time to Repair (Priority 2 Outages)

Definition: Mean Time to Repair (Priority 2 Outages) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Priority 2 Outage Service Requests for in-scope Services in the Contract Month. “Time to Repair” is measured from time Service Request is received at the Level 2 Service Desk to point in time when the incident is resolved or workaround is in place and the Contractor submits the resolved Service Request to the State for confirmation of resolution.

“Priority 2 Outage Service Request” means an incident where the State’s production use of solution Services is still in operation; however, substantial features are unavailable such that there is a serious impact on the productivity of the State personnel.

This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan. The initial Service Level shown for this SLA will be 99.0% and will be validated during the measurement period. Following the measurement period, the initial Service Level will be adjusted to 99.5%. The measurement period will be as mutually agreed by the Parties, not to exceed six months.

In the event of “go live” of new functionality, an Upgrade, or significant change in the architecture of the Application environment, this Service Level will be suspended temporarily from the time the “go live” of the applicable Change through two (2) business days following completion of stabilization criteria in accordance with the transition to production plan.

Formula: Mean Time to Repair (Priority 2 Outages)



Measurement Period:

Accounting Month



Per incident



Outages)Green <= 8 hoursYellow > 8 hours and <= 12 hours

Red > 12 hours

Page [124]



9.7.3.1 Service Level Objective

Specification: Incident Resolution – Mean Time to Repair (Priority 3 Outages)

Definition: Mean Time to Repair (Priority 3 Outages) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Priority 3 Outage Service Requests in the Contract Month.

“Time to Repair” is measured from time a Service Request for in-scope Services is received at the Level 3 Service Desk to point in time when the incident is resolved or workaround is in place and the Contractor submits the resolved Service Request to the State for confirmation of resolution.

“Priority 3 Outage Service Request” means that a solution service is still available, but a non-critical function is unavailable or a workaround is available.

This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the stabilization and transition to production plan. The initial Service Level shown for this SLO will be 99% and validated during the measurement period. Following the measurement period, the initial Service Level will be adjusted to 99.5%. The measurement period will be as mutually agreed by the Parties, not to exceed six months.

Formula: Mean Time to Repair (Priority 3 Outages) =



Measurement Period:

Accounting Month



Per incident

9.7.3.2 Service Level Measures


Incident Resolution – Mean Time to Repair (Priority 3 Outages).

Green <= 24 hoursYellow > 24 hours and <= 36hours

Red > 36 hours

Page [125]


9.7.4 Service Availability – Application Availability


Specification: Service Availability – Application Availability

Definition: Application Availability for each in-scope Platform,

Application Availability means access to the production system is enabled; log-in permitted from the local user LAN and business transactions can be executed. While it is dependent on hardware, system software and Third Party software availability the expectation is that the Contractor will implement monitoring instrumentation that validates availability to the point of presence within the Service Delivery Center.

Formula: Application Availability

= (Total application scheduled uptime minus total application unscheduled downtime)

x 100

(Total application scheduled uptime)

Measurement Period:

Accounting Month

Data Source: Monthly Service Level Report


Continuous (24 hours a day, 7 days a week)



Service Availability - Application Availability

Green >= 99.9Yellow >= 99.7 and < 99.9

Red <99.7

Page [126]


9.7.5 System Performance & Responsiveness


Specification: System Performance & Responsiveness

Definition: System Performance & Responsiveness will be based on the following:

Upon service transition and acceptance, Contractor will perform end-to-end service class performance baselining (e.g., network time, application/session response time, system time, and network return time) for key service elements as mutually agreed.

Formula: System Performance & Responsiveness

= Total service elements that do not meet the baseline requirements

Measurement Period:

Monthly



Monthly



Incident Resolution - Incident Triage and Closure and Recidivist Rate

Green = 0Yellow >= 1 and <2

Red >= 2

Page [127]


9.7.6 Incident Resolution - Issue Triage, Closure and Recidivist Rate


Specification: Incident Resolution - Incident Triage, Closure and Recidivist Rate

Definition: Incident Triage, Closure and Recidivist Rate will be determined by monitoring compliance with the following four key performance indicators (KPI):

Incident Triage: Contractor to indicate high-level diagnosis and estimate to remedy to the State within 30 minutes of acknowledgement

Incident Closure: Incident to be documented with root cause remedy, (where root cause is within Contractor’s control), and procedures to eliminate repeat of incident within 24 hours of incident close

Incident Recidivist Rate: Closed incidents not to reappear across all in scope Services no more than 2 times following incident closure.

Incident means any Priority 1 incident where the Services for which Contractor is responsible under the SOW are unavailable.

Formula: Issue Triage, Closure and Recidivist Rate

=

(Total Priority 1 Incidents for which Contractor is responsible under the SOW, where solution Services

are unavailable) - (Number of Incidents where the KPI was not in compliance)

x 100

(Total Priority 1 Incidents where Services for which Contractor is responsible under the SOW are

unavailable)

Measurement Period:

Half year

Data Source: Incident Management System


Per six month review cycle



Incident Resolution - Incident Triage and Closure and Recidivist Rate

Green >= 99.5Yellow <= 99.5 and > 99.3

Red < 99.3

Page [128]


9.7.7 Capacity Monitoring & Planning – Capacity Utilization Flag


Specification: Capacity Monitoring & Planning – Capacity Utilization Flag

Definition: Capacity Monitoring & Planning – Capacity Utilization Flag will be determined by monitoring compliance with the following five key performance indicators (KPI):

Contractor Service Delivery Center CPU capacity not to exceed 95% aggregate sustained utilization by Supported server class (compute, file, web etc) for a period of 4 hours or 80% aggregate sustained utilization for a period of 8 hours. If this performance indicator has not been met then Contractor has notified the State and provided a remediation/enhancement plan as set forth in the Process Interface Manual or other supporting documents.

Contractor Service Delivery Center disk capacity (online) not to exceed 80% utilization as measured by both available disk space and available I/O by server class for period of 5 days. If this performance indicator has not been met then Contractor has notified the State and provided a remediation/enhancement plan as set forth in the Process Interface Manual or other supporting documents.

Contractor Service Delivery Center memory usage not to exceed 95% aggregate sustained utilization by server class for period of 4 hours. If this performance indicator has not been met then Contractor has notified the State and provided a remediation/enhancement plan as set forth in the Process Interface Manual or other supporting documents.

Data center LAN and Wide Area connectivity elements not to exceed 90% aggregate sustained utilization on primary network backbone. If this performance indicator has not been met then Contractor has notified the State and provided a remediation/enhancement plan as set forth in the Process Interface Manual or other supporting documents.

Flag, for the purposes of this Service Level, means a Contractor notification to the State as set forth in the Process Interface Manual or other supporting documents.

Formula: Capacity Utilization Flag

= (Number of instances where individual KPI’s were not in compliance)

Measurement Period:

Accounting Month



Per monthly reporting cycle

Page [129]



GYR StateCapacity Monitoring & Planning – Capacity Utilization

FlagGreen <= 5Yellow > 5 and <= 7

Red > 7

Page [130]


9.7.8 Data Back-up & Restoration – Back-up Success Rate


Specification: Data Back-up & Restoration – Back-up Success Rate

Definition: Successful backups are defined as those resulting in all data collected from the last backup, which is stored on approved media and transported to a secure area, and ready for restoration.

Contractor will not be responsible for unsuccessful backups that are outside of Contractor’s control.

This Service Level begins upon completion of stabilization criteria and a measurement period as documented in the stabilization and transition to production plan. The initial Service Level shown for this SLA will be 99.0% and will be validated during a measurement period. Following the measurement period, the initial Service Level will be adjusted to 99.9%. The measurement period will be as mutually agreed by the Parties, not to exceed six months.

Formula: Backup Success Rate

(Total Number of Successful Backups) x 100

(Total Number of backup attempts)

Measurement Period:

Accounting Month






Data Back-up & Restoration – Back-up Success Rate

Green >= 99.9Yellow >= 99.7 and < 99.9

Red < 99.7

Page [131]


9.7.9 Data Back-up & Restoration – Restoration Time


Specification: Data Back-up & Restoration – Restoration Time

Definition: Data Back-up & Restoration will be determined by monitoring compliance with the following four key performance indicators (KPI):

Contractor to begin restoration process for onsite data within one business hour of request.

Contractor to begin restoration process for offsite data within four business hours of request.

The measurement will be based on the difference between the open time stamp of the trouble ticket requesting the restore and the start time of the restoration job.

Business hours will be defined in the Process Interface Manual or other supporting documentation.

Formula: Restoration Time (Total number of requests for restoration) - (Number of requests for restoration where the KPI was not in compliance)

x 100

(Total number of requests for restoration)

Measurement Period:

Accounting Month






Data Back-up & Restoration – Restoration Time

Green >= 99.9Yellow >= 99.7 and < 99.9

Red < 99.7

Page [132]


9.7.10 Scheduled Provisioning – Virtual Machines


Specification: Scheduled Provisioning – Virtual Machine environments

Definition: Scheduled provisioning of virtual machine environments is defined as the planning, management and configuration of the host server and their connectivity to networks and data storage devices to accommodate new requests for service.

Time measurement is from receipt of the provisioning request in the Contractors Service Desk through to visibility of the provisioned machine on the network.

Formula: Provisioning Virtual Machines

(Total number of virtual machine scheduled provisioning requests) minus (number of scheduled virtual machines provisioned in greater than 8 hours)

x 100

(Total number of virtual machine scheduled provisioning requests)

Measurement Period:

Accounting Month



Per provisioning request



Scheduled Provisioning – Virtual Machines

Green >= 99.9Yellow >= 99.7 and < 99.9

Red < 99.7

Page [133]


9.7.11 Scheduled Provisioning – Physical Machines


Specification: Scheduled Provisioning – Physical Machines

Definition: Scheduled provisioning of physical machines is defined as the sourcing, procurement and planning tasks necessary to procure, set up and configure additional Service Delivery Center hardware required by the State, provided that such hardware is available at Contractor’s Service Delivery Center. Set of representative hardware includes:

i. Cabinet (Rack, Power, UPS, KVM)

ii. Hardware (CPU/servers, Disk Arrays, Monitors)

iii. Networking Equipment (Switches)

Time measurement is from receipt of the provisioning request in the Contractors Service Desk through to visibility of the provisioned machine on the network.

Formula: Provisioning Physical Machines

(Total number of scheduled physical machine provisioning requests) -(number of scheduled physical machines provisioned in greater than 2 business days of initial contact with Service Desk)

x 100

(Total number of scheduled physical machine provisioning requests)

Measurement Period:

Accounting Month



Per provisioning request



Scheduled Provisioning – Physical Machines

Green >= 99.9Yellow >= 99.7 and < 99.9

Red < 99.7

Page [134]


9.7.12 User Interaction - Completion of User Deletes


Specification: User Interaction - Completion of User Deletes

Definition: Completion of Deletes defines the timeliness of both emergency and scheduled User Deletes.

Late Emergency User Deletes are defined as anything greater than 1 business hour

Late Scheduled User Deletes are defined as anything greater than 4 business hours

Formula:

Completion of User Deletes =

((Total Emergency User Deletes)-(Late Emergency User Deletes))+ ((Total Scheduled User Deletes) – (Late Scheduled User Deletes)) X 100

(Total Emergency User Deletes) + (Total Scheduled User Deletes)

Measurement Period:

Accounting Month


Frequency of Collection: Per user delete


Page [135]

Individual SLAGYR State

Completion of User Deletes

Green >= 99.5Yellow >= 98.5and < 99.5

Red < 98.5


9.7.13 User Interaction - Completion of User Adds & Changes


Specification: User Interaction - Completion of User Adds & Changes

Definition: Completion of User Adds & Changes defines the timeliness of the creation of new users and the implementation of changes to existing users

Computation of time to complete begins when the identification validation is completed and a ticket is entered into Contractor’s Service Desk, and excludes technical corrections required as stated in the Process Interface Manual or other supporting documentation.

Late User Adds and Changes are defined as anything beyond 4 business hours

Formula: Completion of User Adds & Changes =

(Total number of requests for User Adds & Changes) – (Number of Late User Adds & Changes) X 100

(Total Number of requests for User Adds & Changes)

Measurement Period:

Accounting Month


Frequency of Collection: Per user add and change request


Page [136]

Individual SLAGYR State

Completion of User Deletes

Green >= 99.0Yellow >= 98.5and < 99.0

Red < 98.5


9.8 Service Levels – Security

9.8.1 Security – Security Compliance


Specification: Security – Security Compliance

Definition: Security Compliance will be determined by monitoring compliance with the following five key performance indicators (KPI):

Material compliance with the State IT security policies listed in Supplement Seven

Update of antivirus signatures with most current version every 12 hours

100% of environments (inclusive of memory, disk and other file structures) to be actively scanned for viruses, trojan horses, rootkits and other malware every 24 hours

100% LAN devices actively scanned for open ports, forwarded ports or configurations not in keeping with adherence to the State security policies every 24 hours

100% of environments to be reviewed for inactive/suspended user accounts every 30 days

Formula: Security Compliance Flag

(Total number of individual KPI’s performed per month) minus (Total number of individual KPI’s performed per month that were not in compliance)(Total number of individual KPI’s performed per month)

X 100

Measurement Period:

Accounting Month






Security – Security Compliance Flag

Green 99%Yellow N/A

Red < 99%

Page [137]


9.8.2 Security – Annual Security Review


Specification: Security – Annual Security Review

Definition: Annual Security Review completion will be determined by monitoring compliance with the following three key performance indicators (KPI):

Contractor to provide a non-The State specific audit of the Contractor facilities providing the Services every 12 months through an Contractor SAS-70 report as stated in the SOW.

Contractor to provide the right for a Third Party or the State security personnel to perform an annual security reviews at the Contractors facilities used to provide the Services. Contractor will assist and cooperate with this effort by providing Third Party or the State security personnel with appropriate access to Contractor’s facilities and personnel as required to conduct these reviews.

This Service Level begins upon completion of Transition; and for the SAS-70 report, upon the first SAS-70 report prepared by Contractor’s external reviewer after completion of Transition as stated in the SOW.

Formula: Annual Security Review

(Number of instances where individual KPI’s were not in compliance)

Measurement Period:

Twelve months

Data Source: Annual SLA Review Report


Per twelve month audit cycle



Security – Annual Security Review

Green 0Yellow N/A

Red > 0

Page [138]


9.8.3 Monitoring & Auditing – Security Breach Detection

9.8.3.1 Service Level AgreementSpecification: Monitoring & Auditing – Physical, Network, System Security Breach Detection

Definition: Physical, Network, System Security Breach Detection will be determined by monitoring compliance with the following two key performance indicators (KPI):

Physical, Network, System security breach success notification due within 30 minutes of physical intrusion detection of Contractor’s Service Delivery Center area containing Contractor’s Machines. Notification will be as set forth in the Process Interface Manual or other supporting documents.

Physical, Network, System security breach (attempt, failure) notification due within 1 hour of such physical intrusion detection. Notification will be as set forth in the Process Interface Manual or other supporting documents.

Formula: Security Breach Detection


Measurement Period:

Accounting Month



Continuous (24 hours a day, 7 days a week)



Monitoring & Auditing – Security Breach Detection

Green 0Yellow N/A

Red > 0

Page [139]


9.9 Service Levels – Governance & Compliance

9.9.1 SLA Reporting Timeliness


Specification: SLA Reporting Timeliness

Definition: For service requests activities related to code changes that Contractor commits to a mutually agreed upon delivery date, the percent of resolutions that are completed by the delivery date

Formula: Delivery Date Compliance

(Total Number of Code Changes) - (Number of Code Changes failing to meet agreed Delivery Date)

x 100

(Total Number of Code Changes)

Measurement Period:

Accounting Month







Green >= 95.0%Yellow >= 90.0% and < 95.0%

Red <= 90%

Page [140]


9.9.2 Billing - Billing Content, Timeliness & Accuracy


Specification: Billing - Billing Content, Timeliness & Accuracy

Definition: Billing Content, Timeliness & Accuracy will be determined by monitoring compliance with the following three key performance indicators (KPI):

Content of Contractor invoice will show details as to Charges as specified in the Process Interface Manual. This indicator will not be met in the event that the State rejects an invoice for reasons relating to content.

Contractor will provide electronic billing on or before the date specified in Process Interface Manual.

the State and Contractor will meet each month prior to the submittal of the invoice and jointly agree as to what the specific content of that month’s invoice will be. The SLA will apply if the actual invoice is not the same as agreed to by the Parties.

Formula: Billing Content, Timeliness & Accuracy


Measurement Period:

Quarterly

Data Source: Billing System Feed / Contractor Invoice


Per quarterly review cycle



Billing - Billing Content, Timeliness & Accuracy

Green 1Yellow N/A

Red > 1

Page [141]


9.9.3 Continuous Improvement


Specification: Continuous Improvement

Definition: Continuous Improvement will include the following three key performance indicators (KPI):

Contractor will facilitate a meeting with the State where various opportunities for Continuous Improvement will be discussed. The opportunities may be suggestions to improve operational performance, reduce cost, streamline processes, or other suggestions that provide a benefit for the State.

Contractor will provide a written report prior to these facilitation sessions. This report will, at a minimum, contain the expected costs, benefits, and a high-level timeline with which these benefits can be achieved.

The Continuous Improvement meeting will occur quarterly at a minimum.

Formula: Continuous Improvement


Measurement Period:

Quarterly



Per quarterly review cycle



Continuous Improvement

Green 1Yellow N/A

Red > 1

Page [142]


9.9.4 Asset Management & Refresh – Asset Inventory Element Accuracy


Specification: Asset Management & Refresh – Asset Inventory Element Accuracy

Definition: Asset Inventory Element Accuracy will be determined by comparing the Contractor provided and maintained Asset Management Tracking system records against the State system generated record of Asset Inventory Elements. The scope of this comparison is all hardware (physical and virtual) including equipment and software procured, operated and supported by the Contractor for use by the State, as set forth in the SOW. Contractor will not be responsible for accuracy errors that are not caused by Contractor.

Formula:

Element Accuracy

= (Total Asset Inventory Elements) –(Total Inaccurate Asset Inventory Elements)

(Total Asset Inventory Elements)

Measurement Period:

Accounting Month

Data Source: Asset Inventory Management System





Asset Management & Refresh – Asset Inventory Element Accuracy

Green >= 95% Yellow > 93.5% and < 95%

Red <= 93.5%

Page [143]


9.9.5 Monitoring and Usage Report


Specification: Capacity Monitoring and Usage

Definition: The Capacity monitoring and usage measure is determined by monitoring compliance with the following key performance indicator:

Capacity monitoring and usage report distributed electronically to the State in less than or equal to 7 days following the State accounting period month end.

Formula: Capacity Usage & Planning


Measurement Period:

Monthly

Data Source: Monthly Capacity Monitoring and Report


Per monthly review cycle



Monitoring and Usage Report

Green 0Yellow N/A

Red > 0

Page [144]


9.10 Service Levels – Operations

9.10.1 Operational Process Control & Repeatability – Changes to Production environments


Specification: Operational Process Control & Repeatability – Changes to Production environments

Definition: The changes to production environment measure is determined by monitoring compliance with the following two key performance indicator:

All changes to production environments have an authorization from an approved the State employee

Corresponding updates to the Process Interface Manual or other supporting documents are completed within three business days of receiving and implementing minor approved change request(s)

Formula: Changes to Production environments

(Total number of changes and updates where individual KPI’s were not in compliance for the month)

X 100

(Total number of changes and updates for the month)

Measurement Period:

Monthly






Operational Process Control & Repeatability – Changes to Production environments

Green >= 99.5Yellow >= 98.5and < 99.5

Red < 98.5

Page [145]


9.10.2 Service Availability – Batch Processing


Specification: Service Availability –Batch Processing

Definition: The Batch Processing measure is determined by monitoring compliance with the following key performance indicators (KPI):

Batch processing started on time per the mutually agreed schedule

Monitor batch jobs and report to the State as set forth in the Process Interface Manual, State run book or other supporting documents within 30 minutes after an alert.

The initial Service Level shown for this SLA will be 99.0% and will be validated during the measurement period. Following the measurement period, the initial Service Level will be adjusted to 99.7%. The measurement period will be as mutually agreed by the Parties, not to exceed six months.

Formula: Batch Processing (Total number of batch jobs where individual KPI’s were in compliance for the month)

X 100

(Total number of batch jobs for the month)

Measurement Period:

Monthly






Service Availability – Nightly Batch Processing

Green >= 99.7Yellow >= 98.7and < 99.7

Red < 98.7

Page [146]


9.10.3 Service Quality – System Changes


Specification: Service Quality – System Changes

Definition: The Service Quality & Timeliness System Changes measure is determined by monitoring compliance with the following four key performance indicators (KPI):

99% of system changes or updates (i.e., break fix, configuration, and patches) in planned releases are implemented correctly the first time (OS, Router, BIOS, Microcode and other in-scope code and Applications)

99% of system changes (i.e., break fix, configuration, and patches) in planned releases that do not cause other problems

95% of system changes or updates (i.e., break fix, configuration, and patches) in emergency releases are implemented correctly the first time (OS, Router, BIOS, Microcode and other in-scope code)

95% of system changes (i.e., break fix, configuration, and patches) emergency releases that do not cause other problems

Formula: Service Quality System Changes


Measurement Period:

Monthly






Service Quality – System Changes

Green 0Yellow N/A

Red > 0

Page [147]


9.10.4 Service Timeliness – System Changes


Specification: Service Timeliness – System Changes

Definition: The Service Timeliness System Changes measure is determined by monitoring compliance with the following three key performance indicators (KPI):

Emergency system changes or updates (i.e., break fix, configuration, and patches) to operating systems on Contractor’s Machines to be initiated within 24 hours of the State approved request form and Change Management Process and to be reported complete within 1 hour of completion

Non-emergency system changes or updates (i.e., break fix, configuration, and patches) to operating systems on Contractor’s Machines to be initiated in accordance with the State policies as stated in the SOW and reported within 2 days of post implementation certification

Emergency system changes or updates (i.e., break fix, configuration, and patches) will be defined as set forth in the Process Interface Manual or other supporting documents.

Formula: Service Timeliness System Changes

=

(Total Number of system changes where individual KPI’s were not in compliance per month)

______________________________________

X 100

(Total number of system changes per month)

Measurement Period:

Monthly






Service Timeliness – System Changes

Green >= 99.9 %Yellow N/A

Red < 99.9%

Page [148]


9.10.5 Service Quality & Timeliness – Delivery Date Compliance


Specification: Service Quality & Timeliness – Delivery Date Compliance

Definition: For service requests activities related to code changes that Contractor commits to a mutually agreed upon delivery date, the percent of resolutions that are completed by the delivery date

Formula: Delivery Date Compliance

(Total Number of Code Changes) – ((Number of Code Changes failing to meet agreed Delivery Date)*(Total Number of Days Past Delivery Schedule))

x 100

(Total Number of Code Changes)

Measurement Period:

Accounting Month







Green >= 95.0%Yellow >= 90.0% and < 95.0%

Red <= 90.0%

Page [149]


10 Shared Services Implementation SOW

10.1 GeneralIn addition to the program overview contained in Section 3.4 – Shared Services Implementation Scope, the selected Contractor will be responsible for implementing the Build Phase of the OSSP and managing the roll-out that will create the OSSC. While the State expects the OSSC model to eventually be expanded to handle HCM functionality including Payroll, the current scope is only for financial processes.

The following diagram depicts the major threads and the high-level scope, impact, and outcomes expected of Shared Services.

Shared Services Implementation

Technology / Finance Change Management

Project Management

• PeopleSoft Technical Implementation

• Technical Project Management of Enabling Technology Roll-out

• Development of KPI and SLAs between OSSC and Agencies

Creating and distributing communication materials with content direction from the State

Ensuring common understanding of program and value Training development, delivery, logistics, environments,

data sets, and post-training responsibilities Agency Readiness and Change Management OSSC Readiness and Change Management

Maj

or Th

read

sIm

pact

/Out

com

e

OAKS/OIT State Agencies Shared Services

PeopleSoft and enabling technology implemented

and transitioned to Managed Service

Provider

State Agencies trained and transitioned to

Shared Services

Shared Services processes in place and

running as required

10.1.1 Work to be Quoted as Part of Contractor ResponseThe Build Phase consists of professional and consulting services to validate, manage, and execute the development and implementation of the Shared Services Center as outlined by the SOW.

Page [150]


The Contractor will have overall implementation responsibility for the OSSP. The table below lists the general responsibilities of each task area of the Project.

Task Area DescriptionProject Management Overall Project management, reporting, issue management, etc., including

Project management of the implementation of the enabling technologies to support the OSSC

Technology/Finance Implementation of PeopleSoft Financials build work, new implementation of PeopleSoft CRM, overall technical Project management including technologies being built within the OSSC, development and application of KPIs, complete Finance end-to-end testing

Change Management Change management, communication, training, roles and role descriptions, implementation of designed finance processes for the OSSC, including overall design testing and validation process

Numerous tasks and deliverables are required as part of completing the scope of work for the Build Phase. The State has provided detailed requirements relating to the expected activities and deliverables to be performed within this RFP. To the extent that Contractor believes additional/alternate activities and deliverables are in the best interest of the State, the Contractor may outline these additions/alternates in the appropriate section below, however the State believes the list of deliverables and activities provided represents the minimum requirements which must be met by the Contractor.

10.1.2 TimelineThe current roll-out schedule for go-live of the OSSP, and for the agencies to be rolled into this new Shared Services model, is as follows. The State reserves the right to change dates based on prevailing business conditions or approach to the rollout, however all Proposals should target the July 1, 2009 go-live date for Wave 1.

Wave Timeframe # of AgenciesEnabling Technology In

Scope PeopleSoft Technology in Scope1 July 1,

20091 – 3 OSSC Infrastructure

Telephony (ISD, ACD, CTI)ImagingPeopleSoft CRM

21 Sub-processes, including rollout of Travel & Expense and eSupplier provided in the table below.

2 Fall 2009 Additional 5 Anticipated

Minor enhancements to Enabling Technology

TBD

3 Early 2010 Remaining agencies bringing total to 15

None TBD

10.1.3 PeopleSoft Financials Technology Gap SummaryDuring the Design Phase completed to date, the following items were identified which are required to support the OSSC. The table below includes a summary of these items required for completion. A more

Page [151]


detailed description of each RICE object (Report, Interface, Conversion/Configuration, Enhancement, Workflow) including complexity can be found in the OSSP Software Gap Analysis and the OSSP Software Processes in Supplement Six.

Process Area ID # Sub-Process

P2P FIN20-25 Process Non-PO Vouchers R2R FIN40-10 Process ISTV Transactions - Goods or ServicesR2R FIN40-15 Process ISTV Transactions - Pass Through RevenueP2P FIN20-20 Process PO Vouchers P2P FIN10-20 Create and Approve RequisitionP2P FIN10-30 Maintain POs R2R FIN50-40 Perform Accounting Period CloseP2P FIN20-10 Receive, Inspect, and Accept Goods and Services P2P FIN20-45 Maintain Vouchers P2P FIN20-15 Manage Invoices P2P FIN20-60 Void for Age R2R FIN50-10 Enter and Maintain Chart of Accounts R2R FIN50-26 Journal Approval WorkflowP2P FIN30-10 Manage Inbound Reimbursement Requests (refer to Travel and Expense assumptions in RICE

software gap inventory)P2P FIN30-30 Process Travel Reimbursement Transactions (refer to Travel and Expense assumptions in RICE

software gap inventory)P2P FIN30-40 Audit Expense Reports (refer to Travel and Expense assumptions in RICE software gap

inventory)P2P FIN10-10 Maintain Vendor MasterP2P FIN20-70 Process 1099 Forms P2P FIN50-50 Manage Inquiries/eSupplier (refer to RICE Software Gap Inventory)P2P FIN20-90 Disburse Funds P2P FIN20-55 Cancel Payments

In addition to the above items, the Contractor should refer to the PeopleSoft CRM Section 10.5.2 for details about the requirements of the new CRM application for the OSSC.

The offeror should also note that the OSSP Software Gap Analysis in Supplement Six includes the RICE objects related to the integration/interface with the Imaging Solution provided by a third party, described in more detail in Section 10.5.3.

10.1.4 Cost Proposal GuidelinesThe following table shows the scope of services to be included in the offeror’s cost proposal.

Task Area Wave 1 Wave 2 Wave 3Project Management In-scope In-scope In-scopeTechnology/Finance In-scope Technology Project Technology Project

Page [152]


Management and Finance

Responsibilities (with additional support as

agreed with State)

Management and Finance

Responsibilities(with additional support as

agreed with State)Change Management In-scope In-scope In-scope

10.2 Project Management Requirements

10.2.1 Overview of ScopeThe Contractor will have responsibility to provide overall project management for the task areas of the Shared Services implementation, including:

1. Technology/Finance2. Change Management


Be responsible for overall Project completion; Maintain the overall Project workplan; Ensure deliverables have a detailed project subplan as required by the State to ensure timely

delivery and appropriate quality Ensure that the OSSP has an effective version control mechanism for all documents within the

project document library Ensure that an appropriate “Project Kickoff” occurs and that all integrated workplans are agreed

to by the State from project commencement; Complete status reporting adhering to the PMO policies; Work with the State leadership to ensure that the Project is staffed appropriately; Ensure that required testing activities across both technical and operational components are

completed to minimize Project risk; and Collaborate with the task areas to ensure appropriate cross-team communication and delivery.

10.2.2 Current Team OrganizationBased on the design work completed to date, the following organizational chart has been created to outline the Contractor roles as they would fit into the current team structure. To the extent that the offeror believes an alternative solution would be beneficial to the State, the offeror may present an alternative organizational chart and roles and responsibilities in the response to this section.

Page [153]


10.2.3 Maintain Project PlanThe Contractor must produce a detailed Project Plan, in electronic and paper form, to the Project Representative for approval within ten business days after the State issues a purchase order or other written payment obligation under the Contract. The Contractor must lead a planning session which ensures the following:

A common understanding of the workplan has been established; A common vision of all deliverables has been established; and Clarity on scope of overall project and the responsibilities of the Contractor has been defined

and agreed to by the State.

Thereafter, the Contractor must:

Formally update the Project Plan, including work breakdown structure and schedule, and provide the updated Project plan as part of its reporting requirements during the Project; and

Ensure the Project Plan allows adequate time and process for the development for the State’s review, commentary, and approval.

The State will determine the number of business days it needs for such reviews and provide that information to the Contractor after award and early in the development of the Project Plan. Should the State reject the plan or associated deliverables, the Contractor must correct all deficiencies and resubmit it for the State’s review and approval until the State accepts the Deliverable at no additional cost to the State.

10.2.4 Meeting Attendance and Reporting Requirements. The Contractor’s project management approach must adhere to the following meeting and reporting requirements:

Page [154]


Immediate Reporting - The Project Manager or a designee must immediately report any Project staffing changes to the Project Representative in accordance with Governance Section 7.5.

Attend Weekly Status Meetings - The Project Manager and other Project team members must attend weekly status meetings with the Project Representative and other members of the Project teams deemed necessary to discuss Project issues. These weekly meetings must follow an agreed upon agenda and allow the Contractor and the State to discuss any issues that concern them.

Provide Weekly Status Reports - The Contractor must provide written status reports to the Project Representative at least one full business day before each weekly status meeting.

At a minimum, weekly status reports must contain the items identified below:o Updated GANTT chart, along with a copy of the corresponding Project Plan files (i.e. MS

Project) on electronic media acceptable to the State;o Status of currently planned tasks, specifically identifying tasks not on schedule and ao resolution plan to return to the planned schedule;o Issues encountered, proposed resolutions, and actual resolutions;o The results of any tests;o A Problem Tracking Report must be attached;o Anticipated tasks to be completed in the next week;o Task and Deliverable status, with percentage of completion and time ahead or behind

schedule for tasks and milestones;o Proposed changes to the Project work breakdown structure and Project schedule, if any;o Identification of Contractor staff assigned to specific activities;o Planned absence of Contractor staff and the expected return date;o Modification of any known staffing changes; ando System integration/interface activities.

The Contractor's proposed format and level of detail for the status report is subject to the State’s approval.

Prepare Monthly Status Reports – During the Project, the Contractor must submit a written monthly status report to the Project Representative by the fifth business day following the end of each month. At a minimum, monthly status reports must contain the following:

o A description of the overall completion status of the Project in terms of the approved Project Plan (schedule and cost, if applicable);

o Updated Project work breakdown structure and Project schedule;o The plans for activities scheduled for the next month;o The status of all Deliverables, with percentage of completion;o Time ahead or behind schedule for applicable tasks;o A risk analysis of actual and perceived problems;o Testing status and test results; ando Strategic changes to the Project Plan, if any.

Page [155]


10.2.5 Develop, Submit, and Update Detailed Activity Plans. As part of the Project, the Contractor must develop a Project management plan (Project Plan). The Contractor also must update the plans with more detail throughout subsequent Project phases to address, at a minimum, the following subjects:

Project Plan including (at a minimum):o Project Integration;o Project Scope;o Project Time;o Project Quality;o Project Staffing;o Project Communications;o Project Risks/Issues; ando Project Procurement.

The offeror must develop these plans from information that the State’s Project personnel provide. These State personnel have varying percentages of time to devote to this Project, and the offeror must consider (and specify) time commitment expectations to the Project in creating the Project schedule and when obtaining information from State staff to create the above plans.

10.3 Technology/Finance Requirements

10.3.1 Overview of ScopeThere are five major components of the Technology/Finance requirements, they are listed as follows:

1. PeopleSoft Technical Implementation 2. OSSC Infrastructure Project Management3. OSSC Enabling Technologies Project Management4. Cross-technology Requirements5. Finance Requirements

Of these five components, the Contractor will be directly responsible for the overall Project Management of the Technology/Finance task areas, including the Project Management of the OSSC Infrastructure and Enabling Technologies components.

The Contractor will lead the PeopleSoft Technical Implementation and be responsible for all tasks and responsibilities to fully deliver the Cross-technology and Finance Requirements, as described within this RFP.

10.3.1.1 PeopleSoft Technical ImplementationFor the PeopleSoft development work, the Contractor will be responsible for all tasks and activities to fully implement the functionality outlined in the current design documents, as well as the PeopleSoft

Page [156]


CRM implementation (including technical design) to support the OSSC. The specific requirements are outlined in detail in the following sections of the RFP, and a high-level view of the major components of the PeopleSoft Technical Implementation is provided below:

Wave 1o Implement PeopleSoft CRM for the OSSC o Implement PeopleSoft Travel and Expense o Implement eSupplier Connection o Refine Inter-Agency General Ledger (ISTVs) to support Shared Serviceso Modify the Procure-to-Pay functionality to support Shared Services modelo Integrate/interface PeopleSoft with the Imaging solution

Wave 2o TBD between the State and the Contractor in conjunction with Wave 1 deployment

Wave 3o TBD between the State and the Contractor in conjunction with Wave 1 deployment

10.3.1.2 OSSC Infrastructure Project ManagementWhile the State will be providing resources for each of the functions outlined below, the Contractor will provide Technology Project Management for the:

Implementation of the Technical Facility Design Procurement and Management of the Desktop Solution Procurement and Management of the VoIP/Phone system

10.3.1.3 OSSC Enabling Technology Project ManagementWhile the State will be providing resources for each of the functions outlined below, the Contractor will provide Technology Project Management for the:

Implementation of Telephony Solution (ACD, IVR, CTI) Implementation of Imaging Solution

10.3.1.4 Cross-technology RequirementsSeveral additional deliverables and activities have been identified which apply across the entire Technology/Finance task area. The Contractor will be responsible for the following plans:

Creation of a Disaster Recovery Plan for OSSP Creation of a Business Continuity Plan for OSSP Development of Operational Readiness Plan

Page [157]


The Contractor will work with the Managed Services Provider to ensure continuity between the State’s various Disaster Recovery Plans. Offerors may propose additional cross-technology activities or deliverables in this section.

10.3.1.5 Finance Requirements The Contractor will be testing the finance and cross-functional process to identify potential go-live issues, creating a thorough and comprehensive testing effort including system, performance and user acceptance testing as well as integrated process and operational readiness testing.

10.3.2 Major ConsiderationsFor clarity, the State would like to emphasize the following points:

The State understands the need for the Contractor to validate the current design documentation that was produced during the Design Phase. However, the State believes these designs meet the requirements for the new Shared Services model and expects the Contractor to propose a maximum of four weeks for validation of these requirements. As part of this RFP response, offeror is to outline validation activities and underlying assumptions in consideration of the design documents provided in Supplement Six. The State requires the validation phase begin as early as possible in the project.

For PeopleSoft Financials, the State believes that the OSSP will require additional environments for conducting development and testing given the large amount of business change included within the OSSP scope. The offeror needs to propose a solution that will allow development activities to begin near Day 1 of this effort and will not be affected by the eventual re-purposing of the existing production hardware located at the SOCC.

The Contractor must provide a detailed approach to ensure that all required code synching, retrofitting, regression testing occurs for any components of code that require modification prior to moving the OSSP to production.

The implementation and testing effort associated with integrating/interfacing PeopleSoft with the Imaging Managed Services Provider (MSP) is a critical component of the Contractor’s responsibilities. The Contractor must demonstrate an understanding of how they will work effectively with the Imaging MSP to produce an integrated/interfaced solution that meets the business requirements.

The CRM implementation to support the OSSC is assumed to be a new installation of PeopleSoft. The Contractor must propose the appropriate version of PeopleSoft CRM and PeopleTools. The Contractor must also propose and implement the technical architecture for the new CRM application.

The offeror should assume the State plans to use, for estimating purposes, the current PeopleSoft Enterprise Learning Management (ELM) for organizing end-user training required for the OSSP. Currently, a significant backlog of PeopleSoft delivered patches exists that have not been applied to the ELM application. The Contractor must propose and implement a plan to address the application of these patches. Either patches need to be applied, tested, and

Page [158]


migrated to Production prior to March 1, 2009 or the Contractor will need to resolve any issues that may arise as the OSSP requires ELM for managing the training required for Wave 1. The State requires that the ELM application is current with released patches prior to the training required for Wave 2.

The Contractor must confirm the environment approach to training and describe the plan for technical support and refreshes of the training environments.

10.3.3 Finance RequirementsTesting the finance and cross-functional process is designed to identify potential go-live issues. The Contractor must be dedicated to a thorough and comprehensive testing effort including system, performance and user acceptance testing as well as integrated process and operational readiness testing, drawing on deep expertise in the involved financial processes to ensure that business requirements are met.


Assemble a testing plan to ensure that the integrated process design is reflective of the required business operating environment and covers all major business, technical, integration/interface and operational functions;

Coordinate the PeopleSoft implementation lead(s) activities to promptly track and resolve technical issues;

Coordinate testing with the change management team for timely communication of progress and results as well as helping to schedule training delivery;

Review and support user acceptance testing activities and provide input into the user community’s adoption of shared services processes, technology, and principles based on best practices and similar rollout/enterprise change initiatives; and

Ensure that testing execution completes in a manner that lends itself to training delivery and preparation for rollout.

10.3.4 Technology Project ManagementThe Contractor will have responsibility to provide overall technical project management for all technical aspects of the Shared Services implementation, including the five major components:

1. PeopleSoft Technical Implementation 2. OSSC Infrastructure 3. OSSC Enabling Technologies (including management of the Imaging Services Managed Service

Provider)4. Cross-technology Requirements5. Finance Requirements

The Contractor must:

Be responsible for overall execution of the technical/finance task area; Complete status reporting adhering to the PMO policies;

Page [159]


Maintain the overall technical Project workplan; Ensure that technical Project risks and issues are managed; Work with the State leadership to ensure that the Project is staffed appropriately; Ensure that required testing activities that span the various components of the technical task

area are completed to minimize Project risk; Ensure that the Project is successfully transitioned to Managed Services upon completion; Collaborate with the Change task area to ensure appropriate cross-team communication and

delivery; Manage the integrated testing plan and activities associated with delivery of the OSSP; Manage third party providers on behalf of the State (e.g., Imaging MSP and various enabling

technology service providers); and Ensure that State standards and additional standards described in the Managed Services

sections of the RFP are followed.

10.3.5 Technology StrategyAs part of the project, the Contractor must develop and implement a technology strategy for the PeopleSoft Technical Implementation, which may include technical plans and in keeping with the System Development Life Cycle (Attachment Nine). Example technology plans are provided below:

High level technical work plan, Build plan (including Code Development/Review, Configuration, etc.), Infrastructure plan (including environment management), Security plan, Testing plan (including all test scripts and data required to test to the lowest level), Configuration management plan including system transition strategy, procedures, Change control plan (ensuring code-synching between production support fixes and code

modified by the Project), Deployment plan, Transition plan to Managed Services support, Quality Assurance planning.

The Contractor must develop these plans from information that the State’s project personnel provide. These State personnel have varying percentages of time to devote to this Project, and the offeror must consider overall time commitment requirements to the project in creating the project schedule and when obtaining information from State staff to create the above plans.

10.3.6 Design/Validation PhaseContractor will validate and refine the current technical and functional designs for the PeopleSoft Technical Implementation of Shared Services. Design Phase deliverables are provided for offeror review and estimating in Supplement Six. The Project design validation services will also include the following:

Validate and refine the designs which will include, where applicable based on the size, complexity and requirements of the Project, design of files, databases, forms, user interfaces,

Page [160]


reports, security, audit trails of the transactions processed, provision for parallel testing, development of fallback procedures, provision for recovery procedures from production failures, provision for architecture attributes designed to minimize data loss in instances of Application failures and maximizes system availability, disaster recovery procedures, creation of job scheduling, and provision for on-line viewing of reports.

Validate the architecture designs, inclusive of network and database considerations, as necessary to properly address issues in respective areas of expertise.

Present the final designs to the State for approval. These will be considered completed when they are approved by the State.

As part of the design process, Contractor will also:

Validate/refine PeopleSoft solution designs to support solution requirements; Validate/refine user interaction model which defines applicable standards, solution prototypes,

and visual designs; Validate/refine technical design of required user interfaces, reports and forms; Validate/refine technical design of integrated solution components and interfaces to external

systems; Validate/refine technical design of logical database and data conversions/migrations as agreed

necessary; Compile and maintain solution issue lists; Validate/refine document design specifications and work with State to create applicable

acceptance criteria; Conduct quality and progress reviews with appropriate the State personnel; and Validate testing plans.

In addition to the Design/Validation activities and deliverables specified above, the Contractor will develop a complete set of design documents for the new PeopleSoft CRM to support the OSSC. For further clarification, Contractor should refer to the PeopleSoft Enhancement Estimating Assumptions, Section 10.5, as well as the Major Considerations related to CRM in Section 10.3.2.

10.3.7 Build Phase Contractor will be responsible for generating all code and configuration necessary to complete the PeopleSoft Technical Implementation (PeopleSoft or ancillary) for the OSSP. Contractor will, in its code development, incorporate the use of coding standards, reviews, and audit trails, including release control. User walk-through(s) of the code will be provided upon request. Contractor’s coding will include the creation and testing of test and production procedures and job schedule, as appropriate. Contractor will also perform the following tasks and activities in connection with building Applications:

Perform detailed technical design as agreed appropriate; Build solution components to support approved design specifications as follows:

o Configure, code and customize the solution requirements;

Page [161]


o Configure, code and customize solution user interfaces; o Configure and customize solution reports and forms;

Design and Implement the security (including all security changes required for the Phasing Plan (i.e., Waves 1, 2 and 3))

Integrate/interface with enabling technology service providers (e.g., Imaging MSP, CRM to CTI) Build/configuration the technical architecture (e.g. batch scheduling, interfaces, operations

architecture, etc) Configure and customize integrated solution components and interfaces to external systems; Coordinate with the Infrastructure Management team to implement physical database designs; Use technologically current development tools (e.g., development environments, code

versioning tools, debuggers, compilers and user interface development toolsets) and languages as appropriate to improve programmer productivity, code stability and reusability;

Provide build, prototyping and test environments as required to perform the development work. The build environments will be designed and maintained by the Contractor so that build activities will not adversely affect the production environment and otherwise be representative of the production environment as to minimize issues associated with production release of the developed application software and integrations;

Perform unit test for solution components and assess quality and completeness of results; Document solution and refine applicable acceptance criteria; Coordinate with the Infrastructure Management team to implement required technology

environment changes as mutually agreed; Make use of applicable Contractor practices to enhance code reusability; Compile and maintain issue lists; Develop Applications in accordance with the State’s strategies, principles, and standards relating

to technical, data and Applications architectures as communicated to Contractor. Contractor will contribute to the ongoing development of such strategies, principles and standards through, at a minimum, advising the State of developments in technology which may be applicable to the State’s business requirements;

Conduct Build progress reviews with appropriate State personnel; Coordinate and confirm the State approval of solution components and verification of applicable

acceptance criteria for transition into Test activities; Track and report hours of labor expended on Applications software development activities to

the State. Such time reporting will be standardized, uniform, and detailed down to a low level of detail that reasonably describes the work performed; and

Implement appropriate tools to measure development productivity and report to the State each quarter on productivity efforts and improvements.

The Contractor should note the following concerning the development environments, as well as the assumptions included in Section 10.5:

1) The Contractor should assume that no excess capacity exists on State hardware to support the Project environments. Therefore, the State assumes the Project environments will be created at

Page [162]


the hosting site proposed and provided by the Contractor. However, the Contractor must ensure the Project will not be negatively impacted if Project environments are at the hosting site but Production support environments remain on the State network for a period of time.

2) The operating system, Oracle database version, PeopleTools, etc. are the same for the Project environments as are the case for the PeopleSoft Financials Production support environments, excluding the CRM implementation.

3) The Contractor must ensure that Production Support fixes get migrated to OSSP environments and that retrofitting/regression testing will be performed.

4) The Contractor must develop and implement a plan to retire or repurpose Project environments when they are no longer required.

5) The Contractor must ensure that Project environments have the required connectivity for build and testing purposes to all required Enabling Technologies within the OSSC and the hosted imaging solution.

10.3.8 Testing Phase For the PeopleSoft Technical Implementation, code-based deliverables or elements will be subject to a formal testing and acceptance process that uses objective and thorough test criteria established by the Parties that will allow the Parties to verify that each build meets the specified functional, technical and where appropriate, performance requirements. The testing and acceptance process will be developed for each build as soon as possible after establishing the business and user requirements. The testing and acceptance process will include sufficient audit trails and documentation as required to track and correct issues. The tasks and activities that Contractor will perform as part of the testing and acceptance process includes the following:

Develop and maintain test data repositories as agreed appropriate; Develop test plans, scripts, cases and schedules as agreed appropriate; Perform the following testing activities for solution components and assess quality and

completeness of results including:o System Test / Assembly;o Integration/interface testing and regression testing new releases of existing

applications; ando Performance Test including regression testing new releases of existing applications as

well as the potential performance impacts to current production environments where a risk of impacting performance may be introduced as a result of these elements;

Provide test environments as required to perform the system and user acceptance testing work, and where appropriate performance testing. The test environments will be designed and maintained by Contractor so that test activities will not adversely affect the production environment. Contractor will expand capacity if testing requirements are constrain by the hardware;

Full test of Imaging integration/interface; Full test of CRM to CTI integration/interface;

Page [163]


Perform technical architecture build/configuration testing (e.g. batch scheduling, interfaces, operations architecture, etc);

Support the following testing activities relating to the State’s performance of user acceptance test (UAT) for solution components as follows:

o Develop with the State agreed upon UAT test plans, scripts, cases and applicable acceptance criteria.

o Coordinate UAT execution and acceptance procedures with the appropriate the State participants.

o Record and report UAT results.o Review changes, fixes and enhancements with the participants in the UAT testing. o Correct identified defects and nonconformities in accordance with the acceptance

process. Compile and maintain solution issue lists; Conduct quality and progress reviews with appropriate the State personnel; Coordinate and confirm the State approval of solution components and verification of applicable

acceptance criteria for transition into deployment and production use; and Provide the State with reports on a weekly basis tracking the progress of Contractor’s

performance of testing work, or in the case of user acceptance testing, support of the State activities. In addition, Contractor will provide timely responses to the State’s requests for information and reports necessary to provide updates to the State business units and stakeholders. Contractor will also provide the State with a database extract from the database that tracks progress of Contractor’s performance of testing work.

10.3.9 Pre-Production/Production Deployment PhaseContractor will be responsible for working with the State and its third party contractors, and executing the production deployment and roll-out of the PeopleSoft Technical Implementation to the Production Environment provided by the State.

Deployment includes software deployment to the End User Desktop Equipment or file server elements (if applicable), identification of interfaces and any required conversions/migrations, installation and testing of any required middleware products, installation of server software, and any required testing to achieve the proper roll-out of the Application software.

Contractor will comply with the State required implementation and deployment procedures. This may include, network laboratory testing, migration procedures, the use of any pre-production or pseudo-production environment prior to production migration. Contractor will be responsible for business user support required during the initial weeks of a production deployment as determined by the affected State business units and will maintain the capability to provide enhanced levels of support during the term of the Contract. Contractor will submit to the State, for the State’s approval, a written deployment plan describing Contractor’s plan to manage each such implementation, including working with the State’s MSP, if applicable. The tasks and activities to be performed by Contractor as part of the Deployment Services also include the following:

Page [164]


Execute required data conversions or migrations including, but not limited to, baseline PeopleSoft configuration tables and parameters, and ancillary supporting data as required by the system to function successfully in the production environment;

o Establish data to be used with the new solution by producing new data and reconciling and mapping different data and database representations.

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

o Perform required data matching activities and error reporting.o Document data issues and provide to the State for resolution.o Coordinate and confirm the State approval of data conversion results.

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

Compile and maintain solution issue lists; End to end final validation of the imaging integration/interface solution with the Imaging MSP; End to end final validation of the operational architecture for the OSSP; Conduct quality and progress reviews with appropriate State personnel; Develop, and thereafter maintain and make available to the State, a knowledge base of

documentation gathered throughout the Project's life and allow for re-use of such documentation for future Projects:

o Transition solution support responsibility to the State or MSP as appropriate.o Conduct a post-implementation review process upon the completion of the Project

which will include an analysis of how the business system(s) resulting from the Project compare to the post-deployment performance requirements established for such Project.

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

10.3.10 Post Production Implementation RequirementsFor a period of no less than ninety (90) days unless otherwise agreed by the State, and in consideration of Service Levels then in effect, Contractor will provide sufficient staffing to ensure the overall continuity of the OSSP as it pertains to delivering these services in a production environment either operated by the State or provided by a Managed Services Provider.

In the event that a Priority 1 or 2 issue (or any critical blocking issue) occurs during this 90 day period, this 90 day period may be extended at the sole discretion of the State for a period commencing upon satisfactory resolution of the issue in the production environment. Under no circumstances will the Contractor performance during this period, successful conclusion of this period (i.e., no issues detected for 90 days) be construed as relief from or reduction to any Software Warranty considerations contained in this RFP.

During this period the Contractor will:

Page [165]


Provide personnel with the requisite skills and experience levels in development of the OSSP to answer questions that the State or Managed Services Provider may have;

Address any software defects, gaps, omissions or errors that are discovered in the Contractor’s work as they pertain to operation in a production environment;

Resolve any configuration, performance, compatibility or configuration issues that arise as a result of migration of the Contractor’s work to a production environment;

Document any relevant changes to operational, configuration, training, installation, commentary or other documentation as a result of migration to the Contractor’s work to a production environment;

Assist either the State or Managed Services provider with production issue triage, root cause and remedy analysis and wherever possible propose work-arounds, fixes, patches or remedies (code-based, procedural or environmental) required to successfully transfer and operate the Contractor’s work to a production environment;

10.4 Change Management Requirements

10.4.1 Overview of Change Management OrganizationThe Contractor’s Change Management approach should build on the foundation and governance structure defined during the OSSP Design Phase.

OSSP Change Management is comprised of three teams:

Communications and Training Agency Readiness and Change OSSC Readiness and Change

Because the State recognizes the significant change management effort that will be necessary in order to make the implementation of the OSSC a success, each of the three teams has a State team lead that reports directly to project management and it is required that the Contractor propose a Training Lead and an OSSC Readiness and Change Lead. The scope for each team is outlined in the following sections.

10.4.2 Overview of Change Management ScopeChange management scope for the OSSP includes stakeholder engagement, communications, training, agency readiness, OSSC readiness, all of the components of the Service Management Framework, business process reengineering, workforce transition, and the agency rollout strategy and execution.

For clarity, the table below provides a high-level overview of the activities included in the Change Management Section of the RFP. For the “Contractor Owned” activities, the State will expect the Contractor to take primary responsibility and drive the work effort; for the “Contractor Support” activities, the State will take primary responsibility but will expect the Contractor to provide support; for the “State Owned” activities, the State will be primarily responsible and it is expected that the Contractor would have little to no involvement in these areas. The specific requirements of the Contractor are described in detail in the following sections.

Contractor Owned Contractor Support State OwnedTraining Approach Communication Development and

DeploymentCollaborations with Unions

Page [166]


Training LogisticsCommunications Plan Maintenance and

UpdatesRecruitment Interview Execution

Training Environments Recruitment Interview Materials Business Process Reengineering for Retained Workforce

Training Data Sets Change Readiness Assessments Agency Retained Workforce Organization Design

Service Management Framework Staffing Requirements Communication Content and DirectionWorkforce Transition Approach and

TimelineVendor Readiness OSSC Web Site Hosting

Workforce Transition Plan for the OSSC Training Material Development and Rollout

Organization Design for the OSSCOnboarding process for OSSC EmployeesStakeholder Analysis Maintenance and

Updates

Training Delivery

The State acknowledges the Contractor has experience in this area and seeks to incorporate best practices generally in the marketplace. This section highlights the State’s view of the minimum set of activities, deliverables and milestones required to deliver the OSSP. The offeror must include any additional considerations that would increase the overall probability of success and result in a high quality of delivery.

10.4.3 Design ReviewAt the commencement of the build phase, the Contractor change management team will thoroughly review Design Phase deliverables that relate to change management. This includes but is not limited to the Change Strategy, Communications Strategy and Plan, Leadership Engagement Approach, Training Strategy, and OSSC Organization Design.

At the conclusion of this review, the Contractor change management team will meet with the State change management leads to review any questions or concerns about these Design Phase deliverables and the scope of the build phase.

This approach will be designed to ensure mutual understanding and agreement on the change management plan and approach as soon as possible as the project moves into the build phase and begins developing and executing plans based on the existing strategy and approach documents.

10.4.4 CommunicationsThe level of visibility and attention the OSSP receives is anticipated to increase substantially as the project moves closer to go-live. Expectation management is essential to help ensure that the State and various state agencies are prepared for the OSSC rollout and understand go-live capabilities and the timeline for future improvements.


Create all communication materials with content direction from the State; Maintain and update the stakeholder analysis; Maintain and update the project communications plan and facilitate any meetings necessary to

keep the communications plan up-to-date; Create presentations for the CFO Advisory Group meetings, Governor’s Office briefings, and

various other presentations as required by the State based upon already established templates and formats;

Page [167]


Ensure that all project materials are branded as defined in the Design Phase; Ensure that key stakeholders, sponsors and supporters are equipped with the appropriate

messages and materials to influence behaviors and alignment throughout the organization; Initiate specific communication activities, workshops, and employee forums to build awareness

and create support for the project; Ensure that all project participants have an up-to-date view of the status, progress, objectives

and success criteria for the overall program; Create targeted communications for agencies that have not elected to join the shared services

model or are undecided; Ensure that all communications provide in-depth project information to build a stronger sense

of understanding of the shared services solution and the value it will bring to the State; Attend meetings as required by the State; Craft communications to support the preparation of participating agencies who will be affected

as they roll into the OSSC; Craft communications to support the preparation of impacted outside vendors and third-parties

who will be affected in the way they operate due to the OSSP; Create targeted communications and awareness aids to facilitate change activities associated

with effectively managing the OSSC ; Document success stories and highlight milestones achieved coinciding with go-live and early

experiences with the OSSC’s organization and capabilities ; Develop a communications approach and plan for after go-live; Create and update web content as necessary; and Provide guidance in marketing materials and enterprise communications.

10.4.5 TrainingOSSP training is comprised of four training efforts: training for State-wide process changes, training for OSSC employees, training for central agencies, and vendor training. These four training efforts are collectively divided into six key delivery areas:

Training Development Training Delivery Training Logistics Training Environments Training Data Sets Post-Training Responsibilities

10.4.5.1 Training DevelopmentEnd-to-end process training is expected to incorporate all relevant State policies, procedures and guidance as defined by the State training lead. Existing system training materials may be leveraged for many of the major processes, but it is the Contractor’s responsibility to make the necessary updates to these materials and create any additional content necessary to turn them into comprehensive end-to-end process training for the in scope processes. Examples of existing training materials are available on the OAKS Training Online web site at http://oakspmo.ohio.gov/oaks/training/index.htm.

It is expected that all training materials will be developed in close cooperation with the State training lead and owners and each of these deliverables will require State signoff. The deliverable descriptions

Page [168]

http://oakspmo.ohio.gov/oaks/training/index.htm


provided in the next few paragraphs outline the current view of the State with respect to training and may not include all of the final requirements for the deliverable.


Be responsible for the development of end-to-end process training materials for all processes within the scope of the OSSP, including those that impact the central agencies.

Develop training materials to support the successful transition of existing State employees and new employees into the OSSC and all communications and training materials necessary to enable vendors to use eSupplier and the new vendor contact center.

Deliver to the State training lead a comprehensive training approach and detailed timeline for the following deliverables shortly after the initiation of the Build Phase:

o Training approacho Curriculum designo Annotated outlineso Course designso Comprehensive training pilot

Outline the Contractor’s governing principles and methodology for instructional design, including the methodology for determining training course delivery method(s) as well as selecting training development tools and software;

Include the templates and style guides that will be utilized for training material development and the methodology for conducting task-to-role-to-course mapping;

Develop curriculum designs including a course listing with course descriptions and the rationalization for the division of materials between courses;

Develop estimates for course length and timing and a task-to-course mapping. Create an annotated outline for each course, including designs for hands-on exercises,

scenarios, and role-to-course mapping; Lead a comprehensive training pilot including a complete walkthrough of each training course

with the State training lead, training owners and key business stakeholders. This pilot will serve as a dress rehearsal to verify all significant training issues have been identified and resolved prior to this point. The pilot must be conducted early enough in the timeline to allow the full integration of State feedback prior to train-the-trainer;

Develop training courseware, including job aids, roles and responsibilities, common error identification and remediation, and other operational functions as required to support the OSSP

Work with State resources to develop PeopleSoft scenarios that are “real life” and applicable to State employees to support training;

Work with the State training owners to build the necessary understanding of the needs and requirements of the end user populations;

Collaborate with State training owners to ensure that existing training materials remain viable and trainable while updates are being made;

Identify the required performance skills and any prerequisites necessary to utilize and understand the training and develop any training materials necessary to address skill gaps;

Design and build training exercises to allow trainees to apply what they have learned; Revise training materials based on early experiences and feedback from training delivery

personnel to enhance and streamline ongoing training materials;

Page [169]


Upload and maintain all training materials on the OSSC web site; and Establish and follow procedures for ensuring that the training materials posted to the OSSC web

site are accurate and up-to-date.

The State will: Develop and deliver Transition Workshop materials to educate the agencies on high-level

process changes that will affect all agencies. The goal is to deliver these workshops approximately five months prior to go-live for the state-wide process changes. It is expected that the State will take full responsibility for these workshops, but may contract with the Contractor for assistance (per Section 10.4.5.2 below).

10.4.5.2 Training DeliveryThe Contractor may be required to lead training delivery for the OSSP. The State will determine the extent of Contractor involvement in training delivery in addition to the minimum requirements listed below at a later date.

As part of this activity area, the Contractor will:

Conduct detailed train-the-trainer workshops to prepare trainers for course delivery by focusing on the process and technical aspects of the training curriculum, including adult learning principles and facilitation techniques;

Provide an end user training program that is scalable to the number and frequency of agencies and processes rolling into the OSSC

Design training reviews for both end user training and train-the-trainer and implement a method for evaluating the effectiveness of training that accurately measures whether or not real learning has occurred and how it can be demonstrated

Establish a plan for tracking and reporting on training attendance and effectiveness measures for both end user training and train-the-trainer

Develop an approach and build any necessary tools as part of the OSSC web site to enable daily communication with trainers on any training updates

Perform knowledge transfer to embed the training capabilities within the OSSC Develop an approach and plan for end user support after they have attended training but before

go-live Establish a plan and build any necessary tools to manage the escalation of questions from

training sessions and the communication of answers back out to trainers Develop an approach and plan for communicating with and training vendors on the eSupplier

module and new business processes

To the extent that the State requires the Contractor to lead the training delivery, the Contractor will be required to provide an additional Statement of Work to be used as the basis for a formal Contract change order.

10.4.5.3 Training LogisticsThe State is responsible for providing a Learning Management System (LMS) that is sufficient for managing the training efforts associated with the OSSP. For estimating purposes, as stated in 10.3.2, the Contractor should assume that PeopleSoft ELM will be used to manage training. It is the Contractor’s responsibility to utilize the LMS to manage all scheduling of attendees and facilities for training.

Page [170]



Manage the printing of all necessary training materials and delivery to the training facilities with guidance from the State training lead;

Establish and document procedures and standards for the utilization of the LMS to manage training enrollment;

Perform knowledge transfer of the procedures and standards to State resources; and Develop and rollout training to effectively enable end users to self-enroll in training via the LMS.

10.4.5.4 Training EnvironmentsThe training environments must be sufficient to support the overall training effort, which is expected to entail:

Approximately 13,000 users for travel Approximately 4,000 core users for state-wide process changes Approximately 200 users for OSSC-specific training


Propose, training environment solutions (including hardware requirements) deemed most appropriate to meet the environment needs outlined above, assuming a three month total rollout for training and noting that the practice environment is expected to be retired three months after the final project go-live;

Provide at least three training environments: one environment for training development, one environment for training delivery, and one practice environment (see Section 6 for specifications regarding environment requirements);

Ensure that the training environments are established as indicated by the State, and in line with the various applicable Service Level Agreements and Objectives outlined in this RFP;

Ensure that training environments are operational in line with the training workplan; Ensure support by the technical team for the training environments during training

development and delivery, including executing backups and refreshes as necessary; Establish and maintain all necessary user ids and passwords; Create and execute approach for managing migrations during the training development and

delivery period; Perform a complete code sync after each wave of end user training is completed; and Conduct knowledge transfer to the State team members on all aspects of training environment

utilization and maintenance.

10.4.5.5 Training Data SetsIt is the Contractor’s responsibility to establish and maintain data sets within each environment that are sufficient to support the training development and delivery requirements outlined above.

As part of this activity set, the Contractor will:

Document data set organization, integration across modules, location of source information, and any other information required to understand how data sets were built;

Conduct knowledge transfer to the State; and Comply with all appropriate data sub-setting and masking requirements as directed by the State.

Page [171]


10.4.5.6 Post-Training ResponsibilitiesAfter the final wave of end user training is completed, the Contractor will:

Revise all training materials in a final form to the satisfaction of the State and transition the materials to the State

Establish procedures and documentation for ensuring that the training team is informed of all updates to production after go-live and the training environments are included on the relevant migration paths

Merge the data within the existing training environments with the data in the OSSP training environments

Facilitate a post-training analysis to gather and document lessons learned and update communication and training plans accordingly

10.4.6 Agency Readiness and ChangeAgency Readiness for the OSSP has three major components: agency readiness to support state-wide process changes, agency readiness for the central agencies (Office of Budget and Management (OBM) and the Department of Administrative Services (DAS)), and agency readiness for those agencies entering the OSSC. The high-level activities within each component are outlined in the sub-sections below.

For each of the sub-sections below, the Contractor will:

Provide best practices related to change management as applicable to the State achieving the goals and executing the activities described herein

Provide subject matter expertise, including examples of similar experiences and efforts, key success factors to these experiences, risk mitigation strategies, and other expertise

Provide tools and templates to expedite and facilitate the State’s efforts

The execution of these activities is a State responsibility. However, the State may contract with the Contractor at a later date for support in executing these responsibilities.

10.4.6.1 State-wide Process ChangesAs part of this activity area, the State will:

Identify agencies affected by the OSSP, based on the phased approach outlined in Section 10.1.2 Identify agency readiness tasks that will need to be completed prior to go-live and develop a

plan for rolling out and managing those tasks Support the agencies in successfully completing the agency readiness tasks

10.4.6.2 Central Agency ReadinessAs part of this activity area, the State will:

Evaluate and make any necessary updates to policies, procedures, forms, manuals and existing communications, including updates to the agency web sites

Communicate changes to end user agencies

10.4.6.3 State AgenciesThe primary focus of the State Agency Readiness team will be on preparing the Wave 1 agencies for transition to the OSSC. The State will:

Page [172]


Identify the process components that are being transitioned to OSSC Identify affected positions and determine the workforce implications Identify affected employees and determine which employees will transition to the OSSC and

which employees will be redeployed within the agency Reengineer the retained business processes based on Contractor best-practices as appropriate

to meet the business requirements Develop a new organization design based on Contractor best-practices as appropriate to meet

the business requirements Create an agency-specific workforce transition plan, communications plan and training plan

10.4.7 OSSC Readiness and ChangeThe OSSC Readiness and Change team has responsibility for all activities related to the establishment and operations of the OSSC, including the service management framework. Responsibility for the rollout strategy and portions of the workforce transition plan is shared with the Agency Readiness team. A successful OSS readiness effort has many dependencies on the rest of the change management teams, as well as the functional and technology teams. It will be the responsibility of the Contractor’s OSS readiness lead to drive and manage this cross-team collaboration.

During the project design phase, a strategy or approach was developed for several elements of the service management framework. These approaches are at varying levels of detail and it will be the Contractor’s responsibility to drive the plans for each element to completion and implementation. While greater detail is provided in the sections below on some of the elements of a service management framework, they are not meant to be comprehensive. The offeror must propose the elements appropriate for ensuring the successful implementation and operations of a shared services center.

10.4.7.1 OSS Rollout Strategy Based on the State preferred phased rollout approach (Section 10.1.2), the Contractor will:

Develop a detailed timeline and implementation plan for transitioning agencies into the OSSC that incorporates technology, people, process and change considerations;

Lead the implementation of this plan; Develop a detailed workplan that includes resources, duration, timing, key dependencies, site-

specific considerations, appropriate review periods and risk identification steps; Facilitate communication of the rollout implementation plan to key State stakeholders and

project sponsors and incorporate any changes or alterations as appropriate; Implement the plan to deliver the OSSC to participating State agencies; Provide regular reporting against this workplan to the State; Identify risks and issues associated with plan execution as well as adjustments to the plan arising

from unforeseen project impacts; and Review and provide input as appropriate to training materials, approach, process

documentation, underlying technology components to help ensure an overall successful OSSC implementation.

Page [173]


10.4.7.2 Workforce Transition Plan and Organizational DesignAs part of the project design phase, the State established an organization design for the OSSC but did not complete any documentation relating to workforce transition, which is deemed critical to the success of the project. The Deliverables described in this section are minimum requirements; the Contractor must work with the State to finalize the exact parameters of the Deliverables in the initial weeks of the Build Phase.


Drive the implementation of the OSSC organizational design; Lead the development and implementation of the workforce transition plan to support the State

in transitioning employees into the OSSC; Enable the OSSC to focus on employee development, continuous improvement, and

accountability; Deliver a comprehensive Workforce Transition Approach document (within three weeks of

initiation of the Build Phase) that includes but is not limited to: o An overall high-level timeline for getting the OSSC operational, including

milestones/deadlines for finalizing staffing needs, identifying agency employees that will be transitioned, training and onboarding, readiness assessments for OSS employees, and post-go-live support

o Best practices and tools for developing an interim staffing plan at the agencies for the time period after employees have been moved to the OSSC but before the OSSC is fully operational

o Best practices and tools for conducting skills assessments, gap analyses, and creating training plans

Build on the foundational Workforce Transition Approach to create a Workforce Transition Plan that includes the following:

o Detailed overall workplan and timeline for establishing and making operational the OSSC o Detailed timeline and milestones for staffing the OSSCo Detailed timeline and milestones for the OSSC onboarding process o Best practices and examples for OSSC position descriptions o Best practices and examples for OSSC recruitment interview materials

Furthermore, to ensure a successful transition of existing and potentially new employees into the OSSC and create the desired culture, the Contractor will:

Develop a plan and timeline for establishing the OSS organization design that was completed during the Design Phase.

Provide best practices and examples of job descriptions and staffing plans and support the State in developing OSS-specific position descriptions.

Develop workforce transition materials including but not limited to skill and competency assessments, gap analysis tools, and supply and demand analysis tools.

Page [174]


Provide best practices and examples for interview materials, including but not limited to behavioral based interview questions focused on acquiring desired skills/competencies, role playing, etc. Scheduling and conducting interviews will be a State responsibility.

Develop a multi-faceted employee development and training program and materials that aid employees in becoming more proficient in the established competencies, skills, knowledge and experiences needed at the OSSC (as determined by the State). Components of this program may include but not be limited to coaching, mentoring, job rotation, instructor led training, etc.

Develop success profiles for each role within the OSSC, to include specific competencies, skills, knowledge and experiences needed to succeed in the position.

Develop and implement an OSSC on-boarding program using best/leading practices to drive/reinforce the desired OSSC culture. The on-boarding program should encompass all aspects from initial interaction with prospective employees through the first thirty (30) days with the OSSC. Elements must include but not be limited to: communications to prospective employees, web presence, day one orientation to the OSSC, coaching/mentoring, relationship development, performance management expectations, and development/reinforcement of the OSSC culture.

10.4.7.3 Shared Services Operations Policies and ProceduresThe Contractor is responsible for ensuring that a comprehensive and integrated set of policies and procedures for OSSC operations are developed, documented, communicated, and ultimately approved by the State. The State will support the development of these deliverables by providing input and guidance as applicable.


Drive the collaboration between the Technology/Finance and Change Management teams to develop the final policies and procedures;

Produce the final policies and procedures manual/documentation with the State contributing content;

Produce final desk instructions for OSS employees; Develop a competency framework to coordinate overall build process elements and rollout

elements; Document process to process integration issues as they are identified and include required

changes to the integrated process design. As a result of these changes identify any gaps that arise, and solicit the input of the team participants in the technology and finance teams to identify the proper resolution for the gap;

Identify outside factors that could potentially affect the integrated process design and propose methods to minimize impact to delivery timeframes, schedules and quality standards associated with the implementation of the project;

Manage changes and updates to the integrated process design and the respective business requirements;

Page [175]


Modify sub-processes, activity profiles, role definitions and the policies and procedures documents as required by the State;

Identify cross-team impacts and dependences and drive the team collaboration necessary to mitigate these impacts; and

Complete additional ad-hoc process design (e.g., designs in support of Wave 2/3) as required to support the OSSC phased rollout as defined in Section 10.1.

10.4.7.4 Customer Service ModelIt is the Contractor’s responsibility to configure, integrate and implement the OSSC customer service model. Implementing the customer service model will be dependent on the successful delivery of the technology task area as described in Section 10.3.


Validate the performance and appropriateness of the implemented technology (e.g., desktops, telephony, networking, PeopleSoft implementation elements and supporting infrastructure);

Work with the Technology/Finance team to configure the CRM software for the OSSC; Work with all necessary project teams to finalize and implement the CFO Dashboard reporting; Work with the Technology/Finance team to finalize and integrate/interface with the imaging

solution and CTI; Test end-to-end technology components to confirm compliance to the agreed-upon customer

service processes; Implement the specified reporting and monitoring of the customer service functions as specified

in operations, process and Agency SLA reporting specifications; Provide an assessment to gauging the initial performance of the OSSC process and technology

model; and Establish baseline statistics in agreement with the State and in accordance with Agency SLA and

process reporting requirements, including measures such as the number of calls handled and addressed the first time, the usage of web self-service, the feedback provided back to the OSSC, call waiting time, and the competence of the staff (for clarification, see the diagram in Section 10.4.7.6 regarding Agency SLAs).

10.4.7.5 Performance Management SystemPerformance management within the OSSC is part of the culture and will require compliance from the OSSC staff as well as the on-boarded agencies. The performance management framework components that were developed during the Design Phase are to be implemented and integrated into the overall shared services training program.


Establish specific Agency SLAs and key performance indicators (KPIs) for the OSSC with input and guidance from the State

Implement reporting and monitoring of the Agency SLAs and performance metrics

Page [176]


Identify areas for operational and technological improvement in order to improve transaction processing quality, increase customer satisfaction and reduce overall call volume

Design Agency SLAs and performance metrics with an associated communications plan to illustrate the overall performance and health of the OSSC and include key metrics for agencies to assess operational performance for processes covered by the OSSC

Integrate the performance management framework into the operational readiness testing effort to ensure that the proposed OSSC performance tracking processes and reporting infrastructure and the information delivery channels perform in accordance with the State requirements

10.4.7.6 Chargeback Model and Agency SLAsAs the OSSP executes the processes and scripts during testing, the underlying Agency SLAs and chargeback model are also to be tested. The OSSC’s ability to meet the performance requirements outlined in the Agency SLAs hinges on several factors, including the standardization of the fiscal processes, the degree to which business processes are supported by the design and the underlying technical elements, the stability of the technology platform as provided under the Managed Services SOW and corresponding Agency SLAs, the shared services technology and infrastructure implemented within the OSSC, and the competence of the staff.

For clarity, the following diagram represents the high-level relationship between the OSSC and the agencies, as well as the various Agency SLAs which will be in place to govern the OSSC performance. The Agency SLAs in this section are depicted in the diagram below.

Shared Services Center

Technology

PeopleSoft Technical Implementation

PeopleSoftFIN

OSSC Inf. Enabling Technology

Process

People

Technical Build SLAs

PS O

pera

tiona

l SLA

s

State Agencies(representative)

OBM

OAKS

DAS

BWC

EDU

TAX

RSC

AGE

DOH

DYS

EPA

DRC

Managed Service

Provider

OAKS/OIT

Agen

cy SL

As

Page [177]


As part of this activity area, the Contractor will:

Finalize the Agency SLAs between the agencies and the Project team with regular communication and involvement from the State;

Implement monitoring of key performance measures and establish performance goals for the first year after go-live;

Provide a documented methodology and plan for identifying opportunities to improve the OSSC’s performance levels in support of participating agencies;

Work with the State to revise Agency SLAs of the OSSC to participating State Agencies during the optimization period and implement improvements in consultation with the State as part of a post-implementation optimization process;

Finalize and implement the chargeback model inclusive of designed reports, backup detail, Agency SLAs and overall effectiveness of the OSSC based on the underlying transaction processing price to Agencies; and

Incorporate any adjustments/updates to the Agency SLAs in light of the chargeback model to ensure overall accuracy in chargebacks, Agency SLA considerations and other service or fee areas for Agencies.

10.4.7.7 Readiness and Change Governance ModelThe Readiness and Change Governance Model provides guidance on scope expansion, prioritization of investments, issue management, and continuous improvement programs. This model acts as a mechanism to maintain and improve the partnership between the agencies and the OSSC. The governance model developed during the design phase is to be implemented and integrated into the OSSC.


Review the governance model developed during the design phase; Incorporate specific governance responsibilities into the appropriate OSSC job profiles; Assist in the implementation of the governance model through the design and clarification of

roles and responsibilities of each working level (governance council, CFO council, process council);

Develop communications and presentation materials for each of the working levels making up the governance model; and

Assist in the development of criteria used in selection of members for the working levels within the governance model.

10.5 Shared Services Estimating Assumptions

10.5.1 Software Gap Analysis RICE Inventory (Wave 1 Only)The RICE software Inventory lists all PeopleSoft Financials Build and Configuration Items for sub-processes that are in-scope for Wave 1. For each gap, the type of build effort (interface, report,

Page [178]


configuration, etc) and its associated complexity is noted. RICE estimates for the Travel and Expense and eSupplier modules are also included. The State recommends that the Contractor use these figures for estimating the build and testing effort.

Functional and technical designs for these noted gaps will be completed prior to the start of the build phase. Several documents resulting from the Design Phase are included in Supplement Six. As noted, the State acknowledges that the Contractor will need to validate these designs as one of the first activities after the start-date.

10.5.2 PeopleSoft CRM for the OSSC The Contractor will complete full system implementation of PeopleSoft CRM to support the OSSC’s focus on customer service. While the State already runs PeopleSoft CRM IT Help Desk, the Contractor should assume that this new CRM install will be a standalone application. The Contractor must propose the appropriate version of PeopleSoft CRM and PeopleTools for this new installation.

The Contractor should propose the technical architecture they recommend. The State is open to a modified technical architecture (operating system, etc.) for this new environments compared to the operating system/hardware configuration currently used by the OAKS applications.

The State assumes that all new environments required for this new installation of CRM will be located at the Contractor’s hosted site from the start of the Project (either the Shared Services Contractor or the Managed Services Contractor, as determined by the State), until it is migrated to the production environment or an alternative development environment provided by the State.

The State plans to use the following CRM modules. The State encourages the Contractor to validate the module list below and offer any additional requirements within the proposal.

Module CommentsSupport The core module needed for the Call Center and other power users of CRM within

the OSSC.Support for Self-Service

Will be used for “light users” to access CRM, such as:1) Employees inquiring about travel and expense issues;2) Agencies opening cases about services being performed at the OSSC; and3) Vendors inquiring about status of invoices/POs.

CTI Integration Needed to allow Third Party telephony tools (ACD, IVR,CTI) to integrate with PeopleSoft CRM

Multichannel Interactions Allow for e-mail/instant messaging integration

Online Marketing Allow for efficient communication to targeted groups

Infosynch server Allow for synching to occur between PeopleSoft CRM and Microsoft Outlook features

Page [179]


The State assumes that the following environments will be needed for the new installation of CRM (offeror should note that these environments are in addition to the current state environments described in Section 8.5.5). The offeror may propose any additional environments if they believe these environments are required to provide a fully functional solution based upon the offeror’s approach.

Demo Patch Development System Test Quality Assurance Production Training Development Training Delivery Training Practice

The State believes the following phases will be required for the CRM implementation. The offeror may propose an alternate solution if they feel that it is in the best interest of State.

Phases General PurposeMini-CRP 1 – 2 week Conference Room Pilot where the CRM requirements that were defined in

the Design Phase are validated and gaps are documents. The Contractor will be required to stand-up a new PeopleSoft CRM Demo or Sandbox environment that will be used for the CRP.

Design Short design phase including but not limited to: Designs for any new reports; Designs for no more than 5 customizations; Configuration Workbooks; Security Design; Technical Architecture Designs; Operations Architecture Design; and Building of the Development environments.

Development Development of any new reports and 5 or less customizations. Unit testing of these development items.Build of security, technical architecture, operations architectureBuild of Testing environments

Testing System TestingIntegration Testing (including the CTI integration)User Acceptance TestingPerformance Testing (Contractor should recommend if this is required)

Deployment End-to-End/Day in the Life TestingOperations Readiness Planning

Production Rollout of the application to the new user base

CRM Assumptions

Page [180]


1) Assume CRM will go-live with the Wave 1 agencies on July 1, 2009.2) Assume 10 new reports will be needed.3) Assume 5 customizations will be needed.4) Assumes no interfacing/integration between CRM and other applications for the Wave 1 go-

live. If interfaces are needed at a future date between PeopleSoft CRM and other or non-OAKS applications, the State will request an estimate from the selected Contractor.

5) Assumes no interfacing/integration between the PeopleSoft CRM application and the imaging solution of the MSP.

6) Assumes the Contractor will propose a solution that will ensure user ids and passwords are in synch between PeopleSoft Financials and the new PeopleSoft CRM application. Since LDAP integration is not currently implemented at the State and may be difficult to implement within this timeframe, the State will accept alternative proposed solutions for achieving a single-sign-on environment.

7) Contractor to determine the level of the effort for the overall configuration of the CRM system.8) Assume up to 250 users of the Support module who are located at the OSSC. Assume that

approximately 20 call center resources will be “heavy” users of the system9) The Contractor should assume up to 5000 users of the Self Service Support module. Assume

very “light” use.10) The Contractor should assume that all testing efforts will be completed entirely by the

Contractor with the exception of User Acceptance Testing and End-to-End Day in the Life Testing. The Contractor will still be required to generate the scripts for UAT and End-To-End Testing but the State will be involved in the execution.

11) The Contractor should ensure that the security design is consistent with security policy outlined in the Managed Services section of the RFP.

10.5.3 Imaging Solution ResponsibilitiesIn addition to this RFP, the State/OSSP plans to release a separate RFP to acquire the services of a Managed Services Provider (MSP) for imaging processing. This solution will be fully integrated/interfaced with the PeopleSoft Financials application.

The Contractor will be required to complete all design/build/test PeopleSoft work needed for the integration of PeopleSoft with the hosted imaging solution, as outlined/listed in the Software Gap Analysis RICE Inventory. In addition, the Contractor will be responsible for the Project Management of this enabling technology.

The Imaging solution will include a variety of types of business documents including but not limited to invoices, purchase orders, package slips, GL backup documentation, intra-agency transaction documentation, vendor documentation, and receipts for Travel and Expense.

There will be a number of methods used to integrate PeopleSoft and the imaging solution as captured in the table below.

No. Option Description PeopleSoft Transaction

Integration Required Outcome

Page [181]


1 Upload supporting documentations into PeopleSoft. No metadata associated with image

Existing transaction (Journal)

The attachment feature in PeopleTools will need to be modified or a custom attach feature will need to be built to allows users to upload documents which will they be saved at the Imaging MSP.

Image will be linked to transaction. No data capture from image.

2 Send coversheet with unique fields to MSPMail copy of document to MSP for scanning (document too big to scan internally)

Existing transaction A coversheet with relevant information will need to be produced from PeopleSoft. Then, PeopleSoft will need to receive data back from the provider to associate the PeopleSoft transaction with the unique identifier for the image.

Link to image with metadata will be provided by MSP and image will be linked to transaction

3 Send document and coversheet with unique fields via fax to MSP

Existing transaction (e.g. Time Sensitive Documents)

A coversheet with relevant information will need to be produced from PeopleSoft. Then, PeopleSoft will need to receive data back from the provider to associate the PeopleSoft transaction with the unique identifier for the image.

Link to image with metadata will be provided by MSP and image will be linked to transaction

4 Send document via mail to MSP or OSSC

No existing transaction (e.g. Invoices)

PeopleSoft will need to be able to receive data from the Imaging MSP (link to image, data captured off of the image) and then use it to reduce the human effort required to enter data into PeopleSoft to produce the transaction. A link will be needed to be added to relevant panels to associate the link with the transaction.

MSP will return link to image, metadata and upon creation in PS, transaction (e.g. Invoice) will be linked to image

5 Send document via fax to MSP

No existing transaction (e.g. Time Sensitive Invoices)



6 Send document via e-mail to MSP

No existing transaction



10.5.4 Design Phase DeliverablesThe State has included in this RFP those deliverables which provide pertinent information to formulate a response. The included items are indicated below. Any additional items from the Design Phase will not be made available during the RFP process and are deemed not pertinent to responding to the RFP. These deliverables will be provided after Contract award.

Page [182]


Deliverable Name

Conceptual Designs and ValidationEnabling Technology Infrastructure Requirements and Conceptual Architecture

Enabling Technology Configuration and Operations Strategy

Enabling Technologies Business Technology RequirementsConversion ApproachInterface ApproachConference Room Pilot ScriptsPeopleSoft Updated Configuration and Operations StrategyPeopleSoft Business Technology RequirementsConference Room Pilot ResultsRICE Software Gap AnalysisStakeholder Analysis Approach

10.5.5 Project EnvironmentsThe State believes that due to the large number of changes that will be required to PeopleSoft Financials and the implementation of the new Travel and Expense and eSupplier connection modules, additional OSSP environments will be required.

The State requires that the Contractor work with the State to ensure appropriate precautions are taken to mask confidential, financial, or otherwise sensitive data when creating the environments from a copy of Production.

Additionally, the State requires that the Contractor subset the Production data during environment creation to minimize storage requirements.

The table below lists the current planned environments. The Contractor must validate the list below and offer recommendations as to the proposed environment strategy in the response.

Description Purpose Size CommentsFinancials V8.8 – Demo Demo instance for

OSSP25GB The Contractor should recommend whether OSSP should use the

existing OSSP demo environment or whether a new environment should be created.

Financials V8.8 – System/Patch

System/Patching instance for OSSP

25GB The Contractor should recommend whether OSSP should use the existing OSSP patch environment or whether a new environment should be created.

Financials V8.8 – Development

Development instance for OSSP

250GB The Contractor should describe how the development environment will be built. The State assumes a copy of Production will be taken and then the data will be masked and subsetted.

Financials V8.8 – Conversion & Interface

Conversion & Interface instance

250GB The Contractor should recommend whether a dedicated conversion/interface environment is required based on the number of

Page [183]


for OSSP conversion/interface RICE items.Financials V8.8 – Configuration

Configuration Instance for the OSSP

250GB [Intentionally left blank]

Financials V8.8 – System Test

System Testing for the OSSP

250GB [Intentionally left blank]

Financials V8.8 – Integration Test

Integration testing instance for OSSP

1TB [Intentionally left blank]

Financials V8.8 – Performance Test

Performance Testing instance for OSSP

1TB The Contractor should recommend whether OSSP should use the existing OSSP performance environment or whether a new environment should be created.

Financials V8.8 –Training Development

Training Development instance for OSSP

25GB The Contractor should assume that new PeopleSoft Financials training environments are required in addition to the production support training environments.

Financials V8.8 – Training Delivery

Execute Training instance for OSSP


Financials V8.8 –Practice Training

Practice Training instance for OSSP


10.5.6 PeopleToolsAs noted in the Current Technical Environment Overview, PeopleTools 8.46 is currently used for PeopleSoft Financials, HCM, and EPM. The State believes that a PeopleTools upgrade should likely be completed near or close to the beginning of the development effort to reduce the probability of issues developing later during development or testing phases that might require a PeopleTools upgrade. The Contractor should provide a recommendation to the State as to when (or if) to complete a PeopleTools upgrade for the OSSP environments and what corresponding approach would be taken for the production support environments.

10.6 AssumptionsThe Contractor must list all the assumptions the Contractor made in preparing the Proposal. If any assumption is unacceptable to the State, the State may reject the Proposal. No assumptions may be included regarding negotiation, terms and conditions, or requirements.

Page [184]


11 Shared Services Service Level Requirements

11.1 Service Level FrameworkThis section sets forth the performance specifications for the Service Level Agreements (SLA) and Service Level Objectives (SLO) to be established between the Contractor and the State. The document contains the tables and descriptions that provide the State framework, expectations relating to service level commitments, and the implications of meeting versus failing to meet the requirements and objectives, as applicable. This document defines the State’s detailed performance, management, and reporting requirements for the Shared Services Implementation Project and to all subsequent Ongoing Project Services that are contracted under future Statements of Work between the State and the Contractor.

Both the State and the Contractor recognize and agree that new categories of Service Levels and performance specifications may be added during the term of the Contract as business, organizational objectives and technological changes permit or require.

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

The Contractor will be required to comply with the following performance management and reporting mechanisms for all Services within the scope of Shared Services SOW, Section 10, procured by the State:

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.

Overall Contract Performance – An overall performance score of the Contractor across all Service Levels. The overall performance score is linked to governance and escalation processes as needed to initiate corrective actions and remedial processes.

11.2 Service Level Specific Performance CreditsEach Service Level (SL) will be measured using a “Green-Yellow-Red” 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 Performance Credit will be due to the State in the event a specific Individual SLA GYR State falls in the “Yellow “or “Red” state. The amount of the Performance Credit for each SLA will be based on the Individual SLA GYR State. Further, the amounts of the Performance Credits will, in certain cases, increase where they are imposed in consecutive months. No Service Level Performance Credit will be payable for the Contractor’s failure to meet a Service Level Objective.

Page [185]


Set forth below is a table summarizing the monthly Performance Credits for each SLA. All amounts set forth below that are contained in a row pertaining to the “Yellow” or “Red” GYR State, represent Performance Credit amounts.

Consecutive Months Credit Table(SLA Performance Credits)


1st Month

2nd Month

3rd Month

4th Month

5th Month

6th Month

7th Month

8th Month

9th Month

10th Month

11th Month

12th Month

RedA

=1.71% of MPC

A + 50% of A

A + 100% of

A

A + 150% of

A

A + 200% of

A

A + 250% of

A

A + 300% of

A

A + 350% of

A

A + 400% of

A

A + 450% of

A

A + 500% of

A

A + 550% of

A

YellowB =

0.855% of MPC

B + 50% of B

B + 100% of

B

B + 150% of

B

B + 200% of

B

B + 250% of

B

B + 300% of

B

B + 350% of

B

B + 400% of

B

B + 450% of

B

B + 500% of

B

B + 550% of

BGreen None None None None None None None None None None None None

The Contractor agrees that in each month of the Contract, up to 12% of the monthly project charges (MPC) associated with the Shared Services Implementation portion of this RFP will be at risk. MPCs are the charges for the deliverables accepted during a given month. The MPC for the Shared Services Implementation will be at risk for failure to meet the Service Levels set forth in the Contract. The Contractor will not be required to provide Performance Credits for multiple Performance Specifications for the same event; the highest Performance Credit available to the State for that particular event will apply.

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, unless the State requests a payment in cash.

Moreover, in the event of consecutive failures to meet the Service Levels, the Contractor will be required to pay 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.

For example, if an Individual SL GYR State is Yellow in the first Measurement Period, Red in the second Measurement Period and back to Yellow in the third Measurement Period for an SLA then the Performance Credit due to the State will be the sum of Yellow Month 1 (B) for the first Measurement Period, Red Month 2 (A + 50% of A) for the second Measurement period, and Yellow Month 3 (B + 100% of B) for the third Measurement period, provided (1) such Performance Credit does not exceed 12% of the MPC (the At-Risk Amount); and, (2) no single Service Level Credit will exceed 20% of the total At-Risk Amount, as stated below:

Page [186]


Service Level Performance Credit payable to the State = (B) + (A + 50% A) + (B + 100% B), based on an illustrative MPC of $290,000;

SLA Calculation EXAMPLEMonthly Project Charge (MPC) = $290,000.00

Monthly At Risk Amount = 12% of MPC = $34,800Maximum for any one SLA = 20% of At Risk Amount = $6,960

GYR State 1st Month 2nd Month 3rd Month

Red 0 $ 0 $ 7,438.50 0

Yellow 1 $ 2,479.50 1 1 $ 4,959.00

Green 6 $ 6 6

Totals 7 $ 2,479.50 7 $ 7,438.50 7 $ 4,959.00

Adjusted Totals by At Risk Amount and 20% per individual SLA Limitations



$ 2,479.50


(Is monthly amount for any one Service Level Credit equal to or less than $ 6,960?) - No

$ 6,960.00



$ 4,959.00

Total Quarterly Credit: $ 2,479.50 + $ 6,960.00 + $ 4,959.00

Total Quarterly Credit: $ 14,398.50

The total of any weighting factors may not exceed 100% of the total At-Risk Amount.

To further clarify, the Performance Credits available to the State will not constitute the State’s exclusive remedy to resolving issues related to the Contractor’s performance.

Service Levels will commence with Project initiation for the Shared Services Implementation.

11.3 Overall Contract PerformanceIn addition to the service specific performance credits, on a monthly basis, an overall SL score (the “Overall SL Score”) will be determined, by assigning points to each SL based on its Individual SL GYR State. The matrix set forth below describes the methodology for computing the Overall SL Score:

Individual SLAs and SLOs GYR State

Performance Multiple

Green 0Yellow 1

Page [187]


Red 4

The Overall SL score is calculated by multiplying the number of SLAs and SLOs in each GYR State by the Performance Multiples above. For example, if all SLAs and SLOs are Green except for two SLAs in a Red GYR State, the Overall SL Score would be the equivalent of 8 (4 x 2 Red SLAs).

Based on the Overall SL Score thresholds value exceeding a threshold of 15, the Executive escalation procedures outlined in Section 7 will be initiated to restore acceptable Service Levels. If a successful resolution is not reached, then the State may terminate the Contract for cause if:

a) The overall SL score reaches a threshold level of 30 per month over a period of 3 consecutive months (equivalent of 50% of the service levels in a red state);

b) The Contractor fails to cure the affected Service Levels within 60 calendar days of receipt of the State’s written notice of intent to terminate; and

c) The State exercises its right to terminate for exceeding the threshold level of 120 per month.

The Overall Contract Performance will not constitute the State’s exclusive remedy to resolving issues related to the Contractor’s performance. The State retains the right to terminate for Overall Contract Performance under the terms of this Contract.

Monthly Service Level Report

On a State accounting 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) accounting day of the following month.

11.4 Service Level Review and Continual Improvement

11.4.1 Service Levels Review Initial Review: Within three months of Project initiation, the Parties will meet to review the Service Levels and the Contractor’s performance and discuss possible modifications to the Service Levels. Any changes to the Service Levels will be only as agreed upon in writing by the Parties.

Ongoing Review: On an ongoing basis, the Parties will meet to review the Service Levels and the Contractor’s performance on a mutually agreed to frequency.

Page [188]


11.5 Service Level CommitmentsThe Contractor will meet the Service Level Commitment for each Service Level set forth in the charts below:

Service Level

State Requirements

SLA or SLO

Support Hours

Required

Response ResolutionDefect Resolution – Priority 1 Items SLA 7x24 Every 4 hours until resolution <= 24 hours

Defect Resolution – Priority 2 Items SLA 7x16 Every 8 hours until resolution <=72 hours

Defect Resolution – Priority 3 Items SLO 5x9 Every 24 hours until resolution <= 7 calendar days

System Test Execution Exit Quality Rate SLA - See specification below -

Blocking Issues Identification and Removal SLA 7x24 Every 2 hours until resolution or agreeable workaround

<=10%%

Regression Testing Performance Issue Find/Fix Rate

SLA - See specification below -

Code Coverage – Automated Test Beds SLO - See specification below -

Milestone Date Delivery SLA - See specification below -

Issue Reporting SLO - See specification below -

Deliverable Acceptance SLO - See specification below -

UAT Process and Environment Support SLO 7x9 Every 2 hours until completion of testing effort

-

Development Methodology Compliance– % SDLC Compliance

SLA - See specification below -

Development Methodology Compliance – % Build and Testing Activities

SLO - See specification below -

Development Methodology Compliance - Issues Detected and Resolved in Production

SLO - See specification below -

The Contractor will meet the Service Level Commitment for each Service Level set forth in the detailed descriptions below:

Page [189]


11.6 Service Levels – Software Development

11.6.1 Defect Resolution – Mean Time to Repair/Resolve (Priority 1 Items)


Specification: Defect Resolution – Mean Time to Repair/Resolve (Priority 1 Items)

Definition: Mean Time to Repair (Priority 1 Items) will be calculated by determining time (stated in hours and minutes) representing the statistical mean for all Priority 1 Defects for in-scope deliverables in the Contract Month. “Time to Repair” is measured from time and Issue is received at the Contractor Issue/Defect tracking system to point in time when the Defect is resolved or workaround is in place and the Contractor submits the repair to the State for confirmation of resolution.

“Priority 1 Defect Service Request” means an incident where the State’s use of a solution service element has stopped or is so severely impacted that the State personnel cannot reasonably continue to work.

This Service Level begins upon Contractor presentation of a deliverable (generally code based) to the State for conducting Acceptance Testing and when this deliverable is initially migrated or otherwise used in a production environment.


=

(Total elapsed time it takes to repair Priority 1 Defect Service Requests)

(Total Priority 1 Defect Service Requests)

Measurement Period:

Accounting Month

Data Source: Monthly Project Report


Per Incident



Defects).Green <=24 hoursYellow >2 4 hours and <= 48 hours

Red >48 hours

Page [190]






“Priority 2 Defect Service Request” means an incident where the State’s Software or Processing Error that results in a partial or intermittent system outage or unavailability, performance Items that result in undue delay of processing business cycle data and creation of a processing backlog, System performance and availability levels not adhering to agreed upon SLAs, the State’s traditional performance levels, and generally accepted and customary industry standards for similar functions or capabilities, a temporary workaround identified but due to processing, hardware, labor or other considerations is deemed unreasonable by the State, or may be a recurring issue with identified or indeterminate cause.



=



Measurement Period:

Accounting Month



Per Incident



Defects).Green <= 72 hoursYellow > 72 hours and <= 90 hours

Red > 90 hours

Page [191]






“Priority 3 Defect Service Request” means an incident where the State’s Software or Processing Error that results in a partial or intermittent system outage or unavailability, performance items that result in periodic, but not otherwise undue delay of processing business cycle data and creation without the creation of a processing backlog that spans a business cycle, system performance and availability levels not adhering to agreed upon performance parameters, the State’s traditional performance levels, and generally accepted and customary industry standards for similar functions or capabilities, errors or omissions in the software, related software elements, operational processes or software integration suite for which a workaround exists, but have been reported to and accepted by the Contractor, an acceptable State agreed workaround has been indentified and implemented, temporary workaround identified with State acceptable processing, hardware, labor or other considerations, may be a recurring issue with identified or indeterminate cause, and items otherwise not classified as a Priority 1 or Priority 2 Defect.



=



Measurement Period:

Accounting Month



Per Incident



Defects).Green <= 7 calendar daysYellow > 7 calendar days and <= 10 calendar days

Red > 10 calendar days

Page [192]


11.7 Service Levels – Testing Performance

11.7.1 System Test Execution Exit Quality Rate


Specification: System Test Execution Exit Quality Rate

Definition: System Test Execution Exit Quality Rate will be determined using the results of Contractor generated pre-test strategy, executed testing cases including functionality, performance, integration, interfaces, operational suitability and other test coverage items comprising a thorough Contractor executed system testing effort.

“System Test Execution Exit Quality Rate” means the inventory of all test cases performed in conjunction with Contractor system testing, or testing otherwise preceding the State’s User Acceptance Testing efforts, presentation of resultant test performance inclusive of identified errors or issues (by priority), impact areas and overall testing results to the State otherwise referred to as “Testing Results”.

This Service Level begins upon Contractor presentation of the aforementioned Testing Results to the State prior to the State conducting UAT. The initial service level shown for this SLA will be 90.0%, exclusive of Priority 1 issues (which must be resolved prior to presentation to the State)and will be validated during an initial measurement period. Following the initial measurement period, and as a result of any production or commercial use the initial Service Level will be adjusted to 95%. The initial measurement period will be as mutually agreed by the Parties, not to exceed three months.

Formula:

Test Quality Exit Rate =

(Total Test Cases and Conditions Failing Contractor System Test Efforts)

(Total Test Cases Executed during System Testing Effort)

X 100

Measurement Period:

Accounting Month



Per Incident


GYR StateSystem Testing Test Execution Exit Quality Rate

Green >= 90%Yellow >= 85%, <90%

Red < 85%

Page [193]


11.7.2 Blocking Issues – Identification and Removal


Specification: Testing of Blocking Issues – Identification and Removal Rate

Definition: A “blocking issue” is an item that is non compliant, or otherwise fails to meet the overall quality standard agreed for work comprising a release or otherwise described in an approved statement of work between the Contractor and the State, that without remediation causes testing or production efforts to be blocked for a delivery element, a logical system function or set of functions up to and including the overall work product contracted by the State.

If a blocking issue is identified, and meets the standard of prohibiting the State to reasonably conclude testing and accepting a release or SOW in part or in full, meaning no more testing (or promotion to a production environment in a reliable manner) can be completed prior to resolution of the blocking issue, the Contractor will remedy the issue or deliver suitable working and commercially viable alternatives to the State as to resume testing activities and meet the business requirement as requested by the State.

This Service Level begins upon Contractor presentation of the aforementioned Testing Results to the State prior to the State conducting UAT. The initial service level shown for this SLA will be 10.0%, will be validated during an initial measurement period. Following the initial measurement period, and as a result of any production or commercial use the initial Service Level will be adjusted to 5%. The initial measurement period will be as mutually agreed by the Parties, not to exceed three months.

Formula:

% of time lost to blocking issues =

(Total Planned Test Time-Time Elapsed Prior to Blocking Issue)+ Test Time Lost to Blocking Condition

(Total Planned Test Time) X 100

Measurement Period:

Accounting Month



Per Incident


GYR StateBlocking Issue Identification and Removal

Green <= 10%Yellow >10%, <= 12%

Red <= 15%

Page [194]


11.7.3 Regression Testing Performance – Issue Find/Fix Rate


Specification: Issue Find/Fix Rate

Definition: Regression Testing Issue find fix rate is the time the Contractor spends resolving issues identified during any testing effort (either System or UAT) as a percentage of the time required to develop the code content associated with a release, enhancement, maintenance fix or otherwise identified for production execution.

The State would like to ensure the Contractor has a prompt response to addressing issues detected during testing and ensure that the Contractor is well aligned with removal of issues detected during testing efforts and that there is a prompt return of the fix to be included a regression testing process.

This Service Level begins upon Contractor presentation of the aforementioned Testing Results to the State prior to the State conducting UAT. The initial service level shown for this SLA will be 10.0% and will be validated during an initial measurement period. Following the initial measurement period, and as a result of any production or commercial use the initial Service Level will be adjusted to 5%. The initial measurement period will be as mutually agreed by the Parties, not to exceed three months.

Formula:

% of Time Repairing Issues =

Time spent in Regression Fix + Time Spent in Regression Test (Days)

(Total Development Time for Release in Days) X 100

Measurement Period:

Accounting Month



Per Incident


GYR StateIssue Find/Fix Rate

Green <= 10%Yellow >10%, <= 12%

Red <= 15%

Page [195]


11.7.4 Code Coverage – Automated Test Beds


Specification: % Automated Code Coverage

Definition: Amount of Code that is covered using automated testing tools for performance, functionality or scenario testing.

The Contractor is to provide best practices in conjunction with the overall testing effort. To facilitate rapid and quality testing, with a high degree of code coverage, the Contractor will employ automated testing tools and techniques where possible to test core scenarios, scenario variations, regression testing and performance testing

This SL will commence upon the delivery of a function set to the Contractor System testing environment and be in effect during the overall testing effort including Contractor efforts, joint efforts or in support of the State activities as agreed and apply to initial testing elements, regression/fix elements, performance and integration testing prior to production use.

Formula:% of Code covered by Automated tools

=

Number of Function Points, Test Cases and Variations covered by Automated Testing Tool

(Total Number of Function Points, Test Cases and Variations Covered within a Testing Period)

X 100

Measurement Period:

Weekly, During Testing

Data Source: Weekly Project Report


Per Test Package


GYR State% Automated Code Coverage

Green >10%%Yellow >5%, <= 10%

Red <= 5%

Page [196]


11.8 Service Levels – Project Performance

11.8.1 Milestone Date Delivery


Specification: % Compliance Milestone Dates

Definition: Amount of committed and accepted Project Milestones achieved on time as per the Project plans.

The Contractor is to produce an overall Project plan inclusive of the milestones, activities and deliverables at the commencement of the Project. Due to the overlapping nature of phases, tasks and activities, a measurement period of 1 calendar month will be established to serve as the basis for the measurement window. Vendor will count all milestones, activities and deliverables to be completed during that measurement window and their corresponding committed delivery dates. Any date variations (positive or negative) will be recorded upon the State’s acceptance of the deliverable and used in the calculation of this SL.

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

Formula:

% Compliance, Milestone Dates =

Total Days Associated in Prevailing Project Period(s) – Total Days Milestones were missed

Total Days Associated in Prevailing Project Period(s) X 100

Measurement Period:

Monthly, During Project



Weekly


GYR State% Compliance Milestone Dates

Green > 90%Yellow >85%, <=90%

Red <= 85%

Page [197]


11.8.2 Issue Reporting


Specification: % Compliance Issue Reporting

Definition: The reporting of any issues impacting the Project to the State for prompt resolution and possible solutions to the State. The Contractor is to promptly report all issues to the Project management and sponsorship personnel within the State upon detection of an issue that will impact overall Project delivery, Project quality, or overall effectiveness of the Project in its intended production operation mode.

Wherever possible, the Contractor must include recommendations as to work-arounds, remedial actions, impact assessment and potential mitigation strategies the State may employ.


Formula:

% Compliance, Issue Reporting

=

=

# Project Issues Identified during reporting period – Issues not reported during period Status Reports - #

issues – Other unreported Issues that arise or are discovered subsequent to reporting dates

# Project Issues Identified during reporting period X 100

Measurement Period:




Weekly


GYR State% Compliance Issue Reporting

Green >90%Yellow >85%, <=90%

Red <= 85%

Page [198]


11.8.3 Deliverable Acceptance


Specification: % Deliverable Acceptance

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

The Contractor must provide deliverables to the State in keeping with agreed levels of completeness, content quality, content topic coverage and otherwise achieve the agreed purpose of the deliverable between the State and the Contractor. For the avoidance of doubt, the deliverables contained in this RFP as they pertain to the Shared Services Implementation Project and general Ongoing Project Services delivery concepts associated with structured software development 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.


Formula:

% Deliverable Acceptance

=

=

# Deliverables Accepted During Period (less the State review Time)

# Deliverables Presented during Period X 100

Measurement Period:




Weekly


GYR State% Deliverable Acceptance

Green >85%Yellow >80%, <=85%

Red <= 80%

Page [199]


11.9 Service Levels – Support of State Activities

11.9.1 UAT Process and Environment Support


Specification: Support of the State User Acceptance Testing (UAT) activities

Definition: The Contractor must support the State UAT activities based on their knowledge of the overall system, responsibility to maintain environments, regression test beds, automated tools and retained developers on the Project to affect prompt and quality resolutions to issues detected by the State during a UAT phase.

Testing environments are to be functional and available to the State to conduct UAT activities, configured with all required base configuration and test data, application code and other elements as required to support the overall State testing effort.

The Contractor must provide a system(s) to accept and track any issues, defects or questions arising from the State during the performance of UAT functions, and acknowledge all issues with an estimate to resolve these issue within 2 business hours of receipt of the issue.

This SL will commence upon the delivery of a function set to the State to perform any User Acceptance or Validation and be in effect during the overall State testing effort including Contractor efforts, joint efforts or in support of the State activities as agreed and apply to initial testing elements, regression/fix elements, performance and integration testing prior to production use.

Formula:

% UAT Support=

# Business Hours, Seven Days Per Week During UAT Period

– (# hours testing environments unavailable or

unusable to perform testing + number business hours beyond standard State inquiries are not

acknowledged and estimated)

# Business Hours, Seven Days Per Week During UAT Period

X 100

Measurement Period:




Weekly

Page [200]



GYR State% UAT Support

Green >85%Yellow >80%, <=85%

Red <= 80%

Page [201]


11.10 Service Levels – Development Methodology Compliance

11.10.1 Development Methodology Compliance


Specification:%SDLC Compliance.

Definition: The Contractor will present and adapt as required a Software Development Lifecycle (SDLC) Methodology to manage the end-to-end software delivery process. This process will be followed.

The Contractor must provide as part of overall Project delivery a proven and tested SDLC to drive and govern the overall software development process and adapt wherever possible to accommodate State considerations and processes. Based on this SDLC and the prescribed development stages (e.g., requirements, design, build, test, deployment) and phase exit documentation, reviews and signoff, this process will be followed for the duration of all development or code based Projects contracted by the State.

Notwithstanding State review and approval cycles, this SL will commence upon Project initiation and will prevail until Project completion.

Formula:

% SDLC Compliance

=

=

# Deliverables, Milestones, Activities, Reviews and Signoffs Missed Per Phase/SDLC Gate

# Deliverables, Milestones, Activities, Reviews and Signoffs Required Per Phase/SDLC Gate

X 100

Measurement Period:




Weekly


GYR State% SDLC Compliance

Green >95%Yellow >90%, <=95%

Red <= 90%

Page [202]


11.11 Service Levels–Project Delivery–Build/Test Activities as a Percentage of Overall Activities



Specification:% build and testing activities

Definition: The Contractor will perform (subject to other SLAs in effect) and prioritize deliverable construction efforts in keeping with overall Project plans and focus effort on deliverable creation and completion associated with the successful delivery of a working Project delivered with quality to a production environment.

The Contractor must report the overall date and quality considerations of the Project delivery for the SOW governing this SL, the amount of time doing constructive efforts in building software elements, deliverables, and associated documentation; and conducting testing (system, integration, interface and performance) as a percentage of overall activities during the measurement period.


Formula:

% Estimating Accuracy

=

=

% Time Spent in Build and Testing Activities

100% X 100

Measurement Period:




Weekly


GYR State% Build and Testing Activities

Green >75%Yellow >70%, <=75%

Red <= 70%

Page [203]


11.12 Service Levels – Project Completion – Issues Detected and Resolved In Production



Specification:Issues Detected and Resolved in Production

Definition: During post-implementation the Contractor must continue to support and promptly resolve any issues emerging as a result of the implementation in a production environment for a period of 90 days or otherwise mutually agreed upon, or until such time as a Managed Services SL is in effect for the element in question.

The Contractor must measure all production exceptions, issues, or problems associated or in conjunction with the initial 90 day period associated with a move of a software release to a production environment regardless of the severity level unless otherwise agreed with the State. Function points from system and user acceptance testing will serve as the basis for counting the total number of elements associated with a release.

This SL will commence upon promotion of code associated with the Project to a production or commercial environment and will prevail until all issues are resolved to the State’s satisfaction or 90 days, whichever is longer.

Formula:

Issues Identified and Resolved in Production

=

=

Total Issues Identified During initial 90 day production Period

Number of Functional Elements included in a Production Release

X 100

Measurement Period:




Weekly


GYR StateIssues Detected and Resolved in Production

Green <= 2%Yellow >2%, <=3%

Red >3%

Page [204]


12 Ongoing Project Services Requirements

12.1 GeneralThe State may from time to time request proposals for the design, development, testing and deployment of new applications or significant application enhancements (“Application Development Projects”). Upon completion of an Ongoing Project Services implementation, the completed application, once meeting the State’s acceptance criteria, will, in most cases, be managed on an ongoing basis as a managed service.

The State may also request staff augmentation services from the Contractor. When staff augmentation services are provided by the Contractor, the SOW and SLAs described in Sections 11 and 13 may not apply (determined at the sole discretion of the State). The State acknowledges that it is responsible for the management of the project and of the work being provided by any Contractor staff providing services under a staff augmentation engagement.

12.2 Ongoing Project Services ObjectivesThe Ongoing Project Services SOW has been defined to achieve the following:

Standardize the Delivery Model for new application development; Facilitate smooth, well-defined transitions of new Projects to steady-state support; Create rate-cards to better control overall development costs; Improve delivery through clearly defined SLAs; Develop governance structure to generate needed process improvements; and Speed up the development lifecycle by reducing the procurement timeline.

12.3 Ongoing Project Services SOW

12.3.1 Development Life Cycle ProposalsThe Contractor will provide a disciplined systems development life cycle methodology for use on Application Development Projects and will adhere to such methodology during the performance of Application Development Projects. The Contractor will adapt this methodology as required to meet the State’s needs. The Contractor will provide the State with a comprehensive description of the methodology, the formal training available if required, the development tools and templates used with the methodology, the project management tools to be used with the methodology, and the plan for implementing the methodology within the State environment. For large changes and releases the full lifecycle SDLC process must be followed. There are a minimum of nine milestone gates required by the State provided below:

Milestone Deliverables

Page [205]


Concept DefinitionConcept Proposal

PlanningBusiness CaseConcept Rough Order of MagnitudeHigh-level Project Schedule

RequirementsDetailed Business ProcessFunctional RequirementsTechnical RequirementsInterface Control DocumentsUpdated ROM

DesignBusiness Process DesignUser Acceptance Test PlanFunctional Design DocumentTechnical Design DocumentSystem and Integration Test PlanImplementation Plan

Component Construction and Testsoftware Development Document

System Integration TestUser Acceptance Test Cases and ProceduresSystem and Integration Test Execution and ResultsUser Training Materials

User Acceptance TestUAT Execution and Results

DeploymentTraining Execution and Final MaterialsSystem Turnover ReviewVersion Description Document

Operations and MaintenanceOperational Performance KPIs and SLAsBusiness Case AnalysisTermination Plan

12.3.2 Submission and Acceptance of the Proposed Contractor OfferAt the State’s request, the Contractor must provide an offer that addresses the State’s SOW for an Application Development Project. The Contractor’s offer must incorporate the SDLC described above (or as agreed to by the State) and as appropriate, be in accordance with all the requirements included in both the Ongoing Project Services and Managed Services sections of this RFP. At a minimum, the Contractor’s offer must include a list of activities to be executed and deliverables to be created,

Page [206]


organized by SDLC Phase. The Contractor’s offer must be priced based on the Rate Card included in the Cost Summary for the completion of the deliverables required by the State’s SOW.

The State will review the Contractor’s offer and provide feedback as needed to the Contractor within 30 days of receipt of the offer. Under no circumstances will work be started without State approval, and the State will have no financial obligation for services performed without State approval.

12.3.3 Maintain Project PlanThe Contractor must produce a detailed Project Plan, in electronic and paper form, to the Project Representative for approval within ten business days after the agreed to start work date. Thereafter, the Contractor must:

Formally update the Project Plan, including work breakdown structure and schedule, and provide the updated Project plan as part of its reporting requirements during the Project; and

Ensure the Project Plan allows adequate time for the State to review, comment on, and approve all Deliverables.

The State will determine the number of business days it needs for such reviews and provide that information to the Contractor as part of the State’s SOW or after award and early in the development of the Project Plan. Should the State reject a Deliverable for any reason, the Contractor must correct all deficiencies and resubmit it for the State’s review and approval until the State accepts the Deliverable. (See Section 12.3.5 for components of the Project Plan.)

12.3.4 Meeting Attendance and Reporting Requirements. Unless otherwise specified in the State’s SOW or mutually agreed to by both Parties, the Contractor's Project management approach must adhere to the following Project meeting and reporting requirements:

Immediate Reporting - The Project Manager or a designee must immediately report any Project staffing changes to the Project Representative

Attend Weekly Status Meetings - The Project Manager and other Project team members must attend weekly status meetings with the Project Representative and other members of the Project teams deemed necessary to discuss Project issues. These weekly meetings must follow an agreed upon agenda and allow the Contractor and the State to discuss any issues that concern them.

Provide Weekly Status Reports - The Contractor must provide written status reports to the Project Representative at least one full business day before each weekly status meeting.

At a minimum, weekly status reports must contain the items identified below:o Updated GANTT chart, along with a copy of the corresponding Project Plan files (i.e. MS

Project) on electronic media acceptable to the State;o Status of currently planned tasks, specifically identifying tasks not on schedule and ao resolution plan to return to the planned schedule;o Issues encountered, proposed resolutions, and actual resolutions;

Page [207]


o The results of any tests;o A Problem Tracking Report must be attached;o Anticipated tasks to be completed in the next week;o Task and Deliverable status, with percentage of completion and time ahead or behind

schedule for tasks and milestones;o Proposed changes to the Project work breakdown structure and Project schedule, if any;o Identification of Contractor staff assigned to specific activities;o Planned absence of Contractor staff and their expected return date;o Modification of any known staffing changes; ando System integration activities.

The Contractor's proposed format and level of detail for the status report is subject to the State’s approval.

Prepare Monthly Status Reports – During the Project, the Contractor must submit a written monthly status report to the Project Representative by the fifth business day following the end of each month. At a minimum, monthly status reports must contain the following:

o A description of the overall completion status of the Project in terms of the approved Project Plan (schedule and cost, if applicable);

o Updated Project work breakdown structure and Project schedule;o The plans for activities scheduled for the next month;o The status of all Deliverables, with percentage of completion;o Time ahead or behind schedule for applicable tasks;o A risk analysis of actual and perceived problems;o Testing status and test results; ando Strategic changes to the Project Plan, if any.

12.3.5 Develop, Submit, and Update Detailed Activity Plans. Unless otherwise specified in the State’s SOW or mutually agreed to by both Parties, the Contractor must develop a Project management plan (Project Plan) and a System Development Life Cycle plan. The Contractor also must update the plans with more detail throughout subsequent Project phases to address, as mutually agreed to be applicable, the following subjects:

Project Plan:o Project Integration,o Project Scope,o Project Time,o Project Quality,o Project Staffing,o Project Communications,o Project Risks/Issues, ando Project Procurement;o System Development:

Page [208]


Requirements Definition, Validation and Design, Construction/Development, Conversion plan, Testing plan (to include all test scripts and data required to test to the lowest

level), Benchmark plan, Implementation plan, Training plan (for users, technical staff), Change management plan, Transition (including system transition strategy, procedures), Quality Assurance, Configuration Management.

The Contractor must develop these plans from information that the State’s Project personnel provide. These State personnel have varying percentages of their time to devote to this Project, and the Contractor must consider their time commitments to the Project in creating the Project schedule and when obtaining information from State staff to create the above plans.

12.3.6 Design Phase Activities & DeliverablesThe Contractor will develop and build technical and functional designs for each Application Development Project. The designs will include, where applicable based on the size, complexity and requirements of the project, design of files, databases, forms, user interfaces, reports, security, audit trails of the transactions processed, provision for parallel testing, development of fallback procedures, provision for recovery procedures from production failures, provision for architecture attributes designed to minimize data loss in instances of application failures and maximizes system availability, disaster recovery procedures, creation of job scheduling, and provision for on-line viewing of reports. Database, network, and infrastructure personnel will be involved in the development of the designs as necessary to properly address issues in their respective areas of expertise. The designs will be presented to the State for approval and will be considered completed when they are approved by the State.

As part of the design process, the Contractor will, unless otherwise specified in the State’s SOW or mutually agreed to by both Parties:

Analyze related the State business processes and identify IT solution requirements. Assess current IT application gaps. Create IT solution designs to support solution requirements as follows:

o Design user interaction model which defines applicable standards, solution prototypes, and visual designs.

o Design reports and forms.o Design integrated solution components and interfaces to external systems.o Design logical database and data conversions as agreed necessary.

Compile and maintain solution issue lists.

Page [209]


Document design specifications and create applicable acceptance criteria. Conduct quality and progress reviews with appropriate the State personnel. Establish assembly, performance, and user acceptance test plans. Coordinate and confirm the State approval of solution design specifications and applicable

acceptance criteria. Provide the State with weekly reports tracking the progress of the Contractor’s design work. In

addition, the Contractor will provide timely responses to the State’s requests for information and reports necessary to provide updates to the State business units and stakeholders.

12.3.7 Build Phase Activities & DeliverablesThe Contractor will be responsible for generating all code (PeopleSoft or ancillary) required to complete and implement each Application Development Project. The Contractor will, in its code development, incorporate the use of coding standards, reviews, and audit trails, including release control. User walkthroughs of the code will be provided upon request. The Contractor’s coding will include the creation and testing of test and production procedures and job schedule, as appropriate. The Contractor will also perform the following tasks and activities in connection with building applications, unless otherwise specified in the State’s SOW or mutually agreed to by both Parties:

Perform detailed technical design as agreed appropriate. Build solution components to support approved design specifications as follows: Configure and customize solution user interfaces. Configure and customize solution reports and forms. Configure and customize integrated solution components and interfaces to external systems. Coordinate with the Infrastructure Management team to implement physical database designs. Use technologically current development tools (e.g., development environments, code

versioning tools, debuggers, compilers and user interface development toolsets) and languages as appropriate to improve programmer productivity, code stability and reusability.

Provide build, prototyping and test environments as required to perform the development work. The build environments will be designed and maintained by the Contractor so that build activities will not adversely affect the production environment and otherwise be representative of the production environment as to minimize issues associated with production release of the developed application software and integrations

Perform unit test for solution components and assess quality and completeness of results. Document solution and refine applicable acceptance criteria. Develop training delivery materials, as follows:

o Perform training needs analysis.o Determine the training material/method of delivery design with the State.o Develop the required training material to support the agreed upon approach and

methods of delivery. Coordinate with the Infrastructure Management team to implement required technology

environment changes as mutually agreed. Make use of applicable Contractor practices to enhance code reusability.

Page [210]


Compile and maintain issue lists. Develop Applications in accordance with the State’s strategies, principles, and standards relating

to technical, data and Applications architectures as communicated to the Contractor. The Contractor will contribute to the ongoing development of such strategies, principles and standards through, at a minimum, advising the State of developments in technology which may be applicable to the State business requirements.

Conduct Build progress reviews with appropriate the State personnel. Coordinate and confirm the State approval of solution components and verification of applicable

acceptance criteria for transition into Test activities. Track and report to the State hours of labor expended on Applications software development

activities. Such time reporting will be standardized, uniform, and detailed down to a low level of detail that reasonably describes the work performed.

Implement appropriate tools to measure development productivity, and report to the State each quarter on productivity efforts and improvements.

12.3.8 Testing Phase Activities & DeliverablesEach Application Development Project, code-based deliverable or element will be subject to a formal testing and acceptance process that uses objective and thorough test criteria established by the Parties that will allow the Parties to verify that each project meets the specified functional, technical and where appropriate, performance requirements. The testing and acceptance process will be developed for each project as soon as possible after establishing the business and user requirements. The testing and acceptance process will include an audit trail capability for tracking and correcting problems. The tasks and activities that the Contractor will perform as part of the testing and acceptance process also include the following, unless otherwise specified in the State’s SOW or mutually agreed to by both Parties:

Develop and maintain test data repositories as agreed appropriate. Develop test plans, scripts, cases and schedules as agreed appropriate. Perform the following testing activities for solution components and assess quality and

completeness of results:o System Test / Assembly.o Product Test including integration testing and regression testing new releases of existing

applications.o Performance Test including regression testing new releases of existing applications as

well as the potential performance impacts to current production environments where a risk of impacting performance may be introduced as a result of these elements.

Provide test environments as required to perform the system and user acceptance testing work, and where appropriate performance testing. The test environments will be designed and maintained by the Contractor so that test activities will not adversely affect the production environment. The Contractor will expand capacity if production requirements constrain the ability to adequately test.

Support the following testing activities relating to the State’s performance of user acceptance test (“UAT”) for solution components as follows:

Page [211]


o Develop with the State agreed upon UAT test plans, scripts, cases and applicable acceptance criteria.

o Coordinate UAT execution and acceptance procedures with the appropriate the State participants.

o Record and report UAT results.o Review changes, fixes and enhancements with the participants in the UAT testing. o Correct identified defects and nonconformities in accordance with the acceptance

process. Compile and maintain solution issue lists. Conduct quality and progress reviews with appropriate the State personnel. Coordinate and confirm the State approval of solution components and verification of applicable

acceptance criteria for transition into deployment and production use. Provide the State with reports on a bi-weekly basis tracking the progress of the Contractor’s

performance of testing work, or in the case of user acceptance testing, support of the State activities. In addition, the Contractor will provide timely responses to the State’s requests for information and reports necessary to provide updates to the State business units and stakeholders. The Contractor will also provide the State with a database extract from the database that tracks progress of the Contractor’s performance of testing work.

12.3.9 Pre-Production, Production Deployment PhaseThe Contractor will be responsible for the production deployment and roll-out of newly developed applications to the production environment. Deployment includes software deployment to the end user desktop equipment or file server elements (if applicable), identification of interfaces and any required conversions, installation and testing of any required middleware products, installation of server software, and any required testing to achieve the proper roll-out of the Application software. The Contractor will comply with the State required implementation and deployment procedures. This may include, network laboratory testing, migration procedures, the use of any pre-production or pseudo-production environment prior to production migration. The Contractor will be responsible for business user support required during the initial weeks of a production deployment as determined by the affected the State business units and will maintain the capability to provide enhanced levels of support during the term of the Contract. The Contractor will submit to the State, for the State’s approval, a written deployment plan describing the Contractor’s plan to manage each such implementation. The tasks and activities to be performed by the Contractor as part of the Deployment Services also include the following, unless otherwise specified in the State’s SOW or mutually agreed to by both Parties:

Execute required data conversions or migrations including, but not limited to, baseline configuration tables and parameters, an ancillary supporting data as required by the system to function successfully in the production environment.

o Establish data to be used with the new solution by producing new data and reconciling and mapping different data and database representations.

Page [212]


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

o Perform required data matching activities and error reporting.o Document data issues and provide to the State for resolution.o Coordinate and confirm the State approval of data conversion or migration results.

Conduct production pilot and fine tune solution as agreed appropriate. Compile and maintain solution issue lists. Support end-user and stakeholder communication efforts.

o Identify required communication recipients and communicate deployment activities to deployment stakeholders.

o Evaluate detailed communication feedback from recipients and stakeholders. o Identify the effectiveness of and need for additional communication.

Determine the requirements for, and participating in, the development of End-User training for the business system(s) resulting from the each Application Development Project including the roll-out of workshops, self-study guides and computer-based training and train-the trainer activities.

Support train-the-trainer activities.o Confirm timeframe, type, content, and target user audience of planned training. o Perform training with the State trainers’ audiences.o Assess the effect and value of conducted training and cooperate to resolve issues

identified. Conduct quality and progress reviews with appropriate State personnel. Develop, and thereafter maintain and make available to the State, a knowledge base of

documentation gathered throughout the project's life and allow for re-use of such documentation for future projects.

o Transition solution support responsibility to the Managed Services Provider.o Conduct a post-implementation review process upon the completion of each

Application development project which will include an analysis of how the business system(s) resulting from the project compare to the post-deployment performance requirements established for such project, establish a performance baseline for the project business systems, and where appropriate document requirements for future performance enhancement of the business systems implemented as part of the project.

12.3.10 Post Production Implementation RequirementsFor a period of no less than ninety (90) days unless otherwise agreed by the State, and in consideration of Service Levels then in effect, the Contractor will provide sufficient staffing to ensure the overall continuity of the project as it pertains to delivering these services in a production environment either operated by the State or provided by a Managed Services Provider.

In the event that a Priority 1 or 2 issue (or any critical blocking issue) occurs during this 90 day period, this 90 day period may be extended at the sole discretion of the State for a period commencing upon

Page [213]


satisfactory resolution of the issue in the production environment. Under no circumstances will Contractor performance during this period, successful conclusion of this period (i.e., no issues detected for 90 days) be construed as relief from or reduction to any Warranty considerations contained in this RFP.

During this period the Contractor will:

Provide personnel with the requisite skills and experience levels in development of the project to answer questions that the State or Managed Services Provider may have;

Address any software defects, gaps, omissions or errors that are discovered in the Contractor’s work as they pertain to operation in a production environment;

Resolve any configuration, performance, compatibility or configuration issues that arise as a result of migration of the Contractor’s work to a production environment;

Document any relevant changes to operational, configuration, training, installation, commentary or other documentation as a result of migration to the Contractor’s work to a production environment; and

Assist either the State or the Managed Services Provider with production issue triage, root cause and remedy analysis and wherever possible propose work-arounds, fixes, patches or remedies (code-based, procedural or environmental) required to successfully transfer and operate the Contractor’s work to a production environment.

12.3.11 Ongoing Project Services Staff AugmentationAs mentioned earlier in this section, the State may request staff augmentation services from the Contractor. When staff augmentation services are provided by the Contractor, the SOW and SLAs described in this, and the following section, may not apply (determined at the sole discretion of the State). For a staff augmentation engagement the State acknowledges its responsibilities to manage, develop and implement project and SDLC plans associated with the requested service. Staff augmentation services will be performed at the direction of the State.

12.3.11.1 Submission and Acceptance of the Proposed Contractor OfferAt the State’s request, the Contractor must provide an offer that addresses the State’s SOW for staff augmentation services. The Contractor’s offer must also be priced based on the Rate Card included in the Cost Summary for the completion of project work.

The State will review the Contractor’s offer and provide feedback as needed to the Contractor within 30 days of receipt of the offer. Under no circumstances will work be started without State approval, and the State will have no financial obligation for services performed without State approval.

12.3.11.2 Additional Work Requirements and ConditionsThe following identify additional work requirements and conditions for staff augmentation services:

1. Contractor staff must submit time sheets for all time and materials work to the State for review and approval on a biweekly basis.

Page [214]


2. Contractor staff must work, at a minimum, during normal core business hours Monday through Friday, except for State holidays. It is the Contractor’s responsibility to ensure staff is working within these parameters and to communicate to the State when exceptions, such as requested time off, personal illness or emergencies arise, to ensure these situations will not impact the project or service.

3. Contractor staff work location will be identified in the SOW. If it is not necessary for Contractor staff to be onsite, the Contractor will be responsible for providing an offsite work location. For Work that requires the Contractor to work onsite, the State will provide each Contractor staff workspace, a workstation, telephone, and needed office supplies.

4. Contractor staff must be prepared to work under unusual working conditions. Unusual working conditions may include, but are not limited to, operation of a computer terminal for long periods of time, working in excess of eight hours per day, working on Saturdays, Sundays and State holidays, and being on call 24 hours a day seven days a week.

13 Ongoing Project Services Service Level Requirements

13.1 Service Level RequirementsFor Application Development Projects, Ongoing Project Services Service Levels are identical to, and will be enforced using the SLAs included in Section 11.0, for the Shared Services Implementation Service Level requirements. The State reserves the right to modify and adjust these service levels to be appropriate to the work performed as part of the authorized SOW for the project.

Service Level requirements may not be applicable to staff augmentation services.

13.2 Project Services Pricing Response and Rate CardOfferors must provide a Rate Card, by project personnel role and experience level as well as Technical role and experience level that is binding over the Contract term. See the Cost Summary section of Attachment Three for additional Pricing Response details.

Page [215]