view liquor management system - managed service ... · web viewroutine maintenance and upgrades the...

Supplement 1Liquor Management System

Application Management and Operations

Table of Contents

1. Business Background and Overview 31.1. Background and Introduction..................................................................................................................................................31.2. Organization of Work Areas....................................................................................................................................................41.3. Service Objectives..................................................................................................................................................................61.4. Offeror Differentiators.............................................................................................................................................................61.5. Current Environment: General Reference Information............................................................................................................7

2. General System Operation, Maintenance and Development Requirements 102.1. Development and Operations Conventions and Requirements............................................................................................102.2. State Infrastructure Obligations.............................................................................................................................................112.3. Ownership and Licensing Considerations.............................................................................................................................12

3. Systems Operations, Maintenance and Support Services (“Steady State Services”) 143.1. Project/System Change Management Support Services......................................................................................................143.2. State Application Help Desk Implementation and Ongoing Level 2 / 3 Help Desk Services.................................................163.3. Environment Review and Advisory Services.........................................................................................................................223.4. Problem Management Support Services..............................................................................................................................223.5. Release and Configuration Management Requirements.......................................................................................................233.6. Break/Fix Services................................................................................................................................................................243.7. Environment Management (Production, Non-Production, QA, Projects, Demo/Train, Test).................................................253.8. System Backup, Backup Validation and Restoration Requirements.....................................................................................263.9. System Environment and Service Architecture, Standards and Advisory Services...............................................................273.10. User Management and Administration..................................................................................................................................273.11. Software Product Evolution and Roadmap Planning/Advisory Services...............................................................................273.12. System and Performance Testing / Validation......................................................................................................................283.13. Program Management & Master Release Calendar.............................................................................................................293.14. Disaster Recovery Planning Support and Implementation....................................................................................................293.15. Legal/Regulatory and Minor Change Requirements.............................................................................................................313.16. Maintaining Solution and Operations Documentation...........................................................................................................323.17. Annual Technology, Infrastructure Optimization: Planning and Updates..............................................................................32

4. Steady State Run Services – Service Level Agreements 344.1. Scope Considerations as they relate to Service Levels and Contractors Supporting of the State.........................................344.2. Service Level Specific Performance Credits.........................................................................................................................354.3. Period Service Level in Full Effect and In-Progress Service Levels......................................................................................364.4. LMP System Steady State Support Services: Service Level Requirements..........................................................................36

5. State Option: Field Service Technician & Technical Support Services 465.1. Remedial Maintenance and Installation Responsibilities.......................................................................................................465.2. Service Request and Response Requirements....................................................................................................................465.3. Preventative Maintenance Requirements.............................................................................................................................465.4. Maintenance Reporting Requirements and Responsibilities.................................................................................................475.5. Preventive Maintenance and Support Plan...........................................................................................................................495.6. Telephone Support and Notification Requirements...............................................................................................................495.7. Solution Element Change Management (Hardware, Software, Devices and Other Offeror Provided Elements)..................50

6. Project Based Services 526.1. Project/Enhancement/Upgrade Delivery: Full Lifecycle SDLC Deliverables and Process.....................................................526.2. Knowledge Transfer and Educational Services.....................................................................................................................646.3. Contractor System Development Environment Management Responsibilities......................................................................656.4. Periodic Technology Refresh and Update Support Services................................................................................................66

7. Identified Major Projects 697.1. Microsoft Dynamics “Next” Upgrade.....................................................................................................................................697.2. Microsoft Azure Migration (Production and/or DR)................................................................................................................747.3. Future Projects, Enhancements and System Evolutions.......................................................................................................797.4. Major Projects, Enhancements, Upgrades and Program Support – Service Level Agreements...........................................80

8. Contractor Staffing Requirements 948.1. Work Location(s) and Contractor Personnel Involvement.....................................................................................................948.2. Microsoft Dynamics and Platform Element Accreditation and Certification Requirements....................................................95

State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services

of 118

8.3. Use of State Provided SharePoint® Collaboration Site, Use of State eMail Exchange®......................................................96

9. Service Establishment Requirements – Transition from Current State to Managed Service 979.1. Overview of Scope................................................................................................................................................................979.2. Service Establishment / Transition Management..................................................................................................................979.3. Service Establishment / Transition Plan................................................................................................................................979.4. Service Establishment / Transition Process..........................................................................................................................989.5. Service Establishment / Transitioning Planning and Analysis...............................................................................................999.6. Service Establishment: Service Operations Design-Build Services......................................................................................999.7. Service Establishment - Transition Test/Acceptance..........................................................................................................1019.8. Service Establishment - Service Deployment.....................................................................................................................1019.9. Service Establishment - Staffing Plan and Time Commitment............................................................................................101

10. Contract Governance 10410.1. Contractor Account Representative....................................................................................................................................10410.2. State Account Representative.............................................................................................................................................10410.3. Participation and Support of Service Management Steering and Oversight Committee......................................................10410.4. Regular Meetings and Conference Calls.............................................................................................................................10510.5. Issue and Dispute Resolution Process...............................................................................................................................10510.6. Billing and Invoicing............................................................................................................................................................10710.7. Service and Work Effort Reporting......................................................................................................................................10710.8. Back-Up Documentation.....................................................................................................................................................10810.9. Correction of Errors.............................................................................................................................................................108

11. Contract Conclusion Requirements: Transition to Successor/State at Contract Termination or Non-Renewal 11011.1. Overview.............................................................................................................................................................................11011.2. Responsibilities...................................................................................................................................................................11011.3. Standards...........................................................................................................................................................................11211.4. Termination Assistance Plan...............................................................................................................................................11211.5. Termination Management Team.........................................................................................................................................11311.6. Operational Transfer...........................................................................................................................................................113

12. Assumptions 11412.1. Support Requirements........................................................................................................................................................11412.2. Pre-Existing Materials.........................................................................................................................................................11412.3. Commercial Materials.........................................................................................................................................................114

13. Reference Information and Additional Exhibits 116


of 118

1. Business Background and Overview

1.1. Background and Introduction

In the spring of 2017, the State, in collaboration with the Ohio Department of Administrative Services, Office of Information Technology, Ohio the Department of Commerce, and Division of Liquor Control (hereinafter “State,” “OIT”, and “Commerce” respectively) successfully optimized and deployed a complex system to preform: supply chain management, inventory control, financial reporting, financial accounting, business reporting, and other business functions for the support of the State’s mission requirements. This system and the underlying software solution was developed, integrated, and implemented at the State by utilizing software and solution elements as provided by the Original Equipment Manufacturer Microsoft, using their supply chain and ERP system Dynamics AX – hereinafter “AX” or in the context of the State’s implementation for the Liquor Management Platform (“LMP”).

The expansion of the LMP system deployment was in part necessitated by the recent exponential growth and dynamic product changes occurring in the spirits business – changes that were unforeseeable just a few short years ago. This growth and change requires a more powerful computing and backup capacity. As an example, the system must deal with the continuing growth in brand variations and subsequent changing demands from the customer base. Since 2011, when the State began discussions to modernize the Division of Liquor Control's technical infrastructure, the number of brands and additional brand variations available in liquor agencies has grown from 2,179 to 2,899 with no real end in sight. That increase of more than 33 percent in four years is only one indication of the rapid changes in the spirits industry. Also during that short time, the number of micro distillers in Ohio has grown from two to 31, with many more promised. These conditions have been introduced at the same time sales have increased by an average of one million barrels a year and revenue growth has accelerated from an annual average of 3.3 percent to yearly average of 5.9 percent for the past three years. In addition, the system must contemplate a future expansion in the number of liquor agencies that may be required as the enterprise surpasses the $1 billion mark in sales.

In addition to the optimization of this system, the State:

Migrated to a new Warehouse/Distribution vendor – and reduced warehouses from four to two Statewide;

Deployed new point of sale, stocktaking, payment and wireless networks to enable streamlined and consistent operations in all liquor agencies;

Revised operating procedures, capabilities, and technology elements to remove legacy operational impediments that remained from the legacy mainframe-based LMP system. Also, re-trained all Stakeholders within the liquor supply chain (e.g., warehouse, distributor, Commerce, OIT, agency etc.) on the most effective use of the new LMP operating environment;

Significantly removed State-specific customizations and enhancements in lieu of using “as-delivered” reports, interfaces/integrations, configurations, extensions, forms and workflows (RICEFW) from the OEM software provider;

Significantly fortified the underlying technical/infrastructure that supports the LMP system including migration to the State’s private cloud as a virtualized environment; provisions for backup/restore/rollback functions, code versioning and control, development under ITIL/CoBIT industry conventions while increasing system capacity, performance, availability and responsiveness in the process.


of 118

(Re)Positioned the LMP system to leverage ongoing upgrades, enhancements, patches and improvements as provided by the OEM via standardization of the platform wherever possible to allow the State to realize the full capabilities of the Microsoft AX platform as available from the software while optimizing its use of the AX platform from a functional, technical, and operational perspective to fully streamline its operations and better serve the public.

Migrated system functions and related User processes to utilize “out of the box” AX features, functions and capabilities as opposed to customized objects, wherever possible;

Increased service levels, systems performance and system quality as well as quality and timeliness of operations arising from the optimization of code, processes and technical aspects of the system;

Implemented OEM best practices and lower cost of operations to help the State achieve a higher level of operational and cost efficiency;

Created a repeatable and predictable business, operational and technical processes based on the State’s anticipated use of the system and experiences to date;

Increased access to centralized financial, inventory and distribution data as well as providing (via reporting and analytics) insights as how to better serve the public through use of the system;

Eliminated work/rework cycles as a result of manual efforts associated with business process, systems operations and maintenance functions;

Increased control over key business processes while streamlining operations using the AX operating paradigm (as opposed to any remaining legacy mainframe applications orientations);

Reduced the State’s exposure to risk from a technical, operations and ongoing maintenance, financial integrity and security perspective;

Improved overall control over critical financial functions (e.g., GL, AP, billing, inventory, ordering, accounting, bailment and broker interaction functions etc.);

Increased the degree of system integration, monitoring, environment currency/consistency and automation; and

Positioned the system for ongoing operation at the State in either a managed on-premise or cloud service.

Due to the complex and dynamic business environment in which the State administers, regulates and operates the ordering, distribution and sales of spirits via liquor agencies and the commercial, off-the-shelf software that this business is supported by, the State has identified requirements to operate, maintain, enhance, upgrade and otherwise utilize the current LMP system. The State’s need for operational knowledge, development and maintenance expertise of the LMP system AX platform, ongoing evolutions to the AX platform, and knowledge of implementation considerations associated with the State’s LMP system, the State has identified several areas that require the ongoing involvement of a Managed Service Provider as they relate to certain Steady State Support Services and Ongoing Enhancements, Upgrades and Program Support matters.

1.2. Organization of Work Areas

The State has identified two distinct Work Areas that are defined and detailed in subsequent sections of this Supplement as unique Statements of Work. In general, there are two Work Areas in which the State requires the support of the Contractor:


of 118

1. Steady State Support Services (Sections 2-4 and 6-9 Requirements). The Contractor is required to provide those services to the LMP system AX platform required to support the day-to-day operation, maintenance, minor upgrades and enhancements, break/fix, technical help desk services, routine reporting, configuration management, release planning and management, support of State deployments to production and assistance with State user matters that cannot otherwise be resolved or addressed by the State. In general, the Steady State Support Services are routine and are required to successfully operate and maintain the system. The services lend themselves to repeatable processes, predictable annual staffing levels, documented responsibilities, and firm, fixed cost levels.

2. Ongoing Enhancements, Upgrade and Program Support Services (Section 5 Requirements). During the term of the Contract, the Contractor may be required to provide those services that are system development oriented or discrete projects that, in general, could be characterized as requiring a full or abbreviated system development lifecycle (e.g., design, development, testing, deployment, etc.). The inclusion of these services allows the State the flexibility to adapt to evolutions to the State business model, changes in regulatory or operating requirements, extensions, optimizations, simplifications or enhancements to the LMP system or product developments by Microsoft for the underlying AX software. These may be either specific to the State or applicable to other customers that utilize the AX software as a result of product developments by the OEM. In general, the Ongoing Enhancements, Upgrade and Program Support Services are non-routine or exceptional and will be addressed by mutual agreement as situational circumstances require, under the conventions of identifying, prioritizing, costing, authorizing and accepting such work.

General Organization of Contractor Work and State Retained/Provided Functions

Each of these areas, with the respective requirements and responsibilities of the State and Contractor are specified later in this Supplement.


of 118

1.3. Service Objectives

As a result of the recent optimization of the State’s LMP system, and in light of the of the State’s Liquor enterprise, the State has identified several objectives that must apply to any contracted relationship going forward. Specifically:

Objective Area Key Service Objectives and Offeror Differentiators

Service Delivery Implement and follow a robust ITIL based delivery model

Leverage of modern tools, techniques and processes

Defined roles & responsibilities with no gaps or non-complimentary overlaps

Accountability and ownership by all parties and stakeholders

Delivery Team and Personnel

Seek to “further the art” as opposed to “strictly manage Profit and Loss (P&L)”

Seek challenges and serve the State by going the extra mile

Integrated with State service delivery teams and partners

Fluent and viewed as experts in their respective disciplines and work as a cohesive team with the State as opposed to “operational silos”

Operational Reliability and Discipline

Robust planning, design, build, test, and deployment processes

Robust change and communications management

Reliable, repeatable and robust execution that results in Operational Quality

Tool and Process centric support of operations

Delivery Culture Collaborative, collegial and integrated with State operations teams

Focused on State objectives and outcomes in addition to meeting minimum requirements

Strict adherence to time, quality, budget and contractual commitments

Change Management and Control

Changes to production (code, process, configuration, reports and otherwise) controlled with versioning, testing and verification

Change management and environment changes supported by processes and tools

High-touch communications and expectation management with LMP service delivery and LMP stakeholder organizations

Security, Reliability and Repeatability

Continue to operate in a secure and reliable environment that protects sensitive operational information contained in the LMP system

Continue to ensure operations are reliable and repeatable from a service quality and predictability perspective

Adhere to required Service Level Agreements while striving for continuous improvement

Cost Considerations Maintain LMP operational cost profile while seeking to optimize delivery through automation, elimination of redundancy or non-value added activities

Support the extension of the LMP investment through supporting the State in retiring legacy applications and business processes through Return on Investment (ROI) positive projects

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.

1.4. Offeror Differentiators

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

Microsoft Dynamics/AX relationships, alliances or awards that demonstrate a commitment to Microsoft AX and a long-standing track record of successful deliveries and customer experiences;


of 118

Significant customer references 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;

Access to best practices that the offeror has developed with customers that result in rapid, high quality and low cost operational usage of Dynamics 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 and seasonal consumption 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 Dynamics 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 Service Delivery and Project risk wherever possible;

Microsoft Dynamics AX center of excellence or “laboratory” type of environment where best practices and methodologies are designed and refined in the context of new Dynamics capabilities, releases, versions or modules; and

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.

The 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, as an Interval Deliverable Agreement (IDA) for future Work:

Additional AX module and capability implementation services; and

Related Dynamics 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 Dynamics related activities.

1.5. Current Environment: General Reference Information

The following information and statistics are provided to aid offerors in understanding the current scope of LMP. Additional materials that may be of assistance are provided in the Section 13 of the RFP.

Microsoft Dynamics AX 2012 R3 CU10 has been deployed as the base software installation version.

The number of high-level business processes contained in each functional area are as follows:

Functional Area High Level Business Processes

Warehouse 35


of 118

Retail 37

Finance 25

Administration 4

The solution currently leverages a limited set of application integration and reporting components summarized in the table below:

Extension Components Number

Custom Reports 30

External Batch Interfaces 10

Sales Reporting & WebAPI Interface

The Dynamics AX environment leverages a custom-built web service approach for agency integration of price and product data and nightly sales reporting.

Nightly sales reporting is processed via an inbound web service which approximately 15 different integrations interface with on behalf of nearly 500 Contract Liquor Agencies.

Price and product data can be requested on demand by Contract Liquor Agencies through these integrations.

Handheld Functionality

The State has implemented handheld scanning functionality in its Contract Liquor Agencies and Bailment Warehouses utilizing an RF-Smart software package integrated with Microsoft Dynamics AX. Business functions managed via the handheld devices include, but are not limited to:

Agency Receiving

Agency Order Management

Inventory Adjustments

Agency Inventory Cycle Counting

Warehouse Receiving

Warehouse Order Picking

Warehouse Transportation Scanning

Item & Inventory Inquiries

Mobile Printing

Wholesale Terminal Support

Each Contract Liquor Agency which manages and fulfills wholesale liquor sales is outfitted with a wholesale order management terminal inclusive of the following components:

HP Retail Solution (State-imaged Windows 10 touchscreen point of sale system)

Dynamics AX mPOS software – Version AX 2012 R3 CU10 with State customization

Thermal Receipt Printer (4” Citizen CT-S4000 or 3.5” HP FK224AT)


of 118

Keyboard, Video, Mouse

The State maintains documentation outlining the design and objects associated with existing modifications for reports, online customizations, and interfaces that will be reusable for future upgrade efforts to support their reapplication, upgrade or modification of these modifications.

Additional details can be found in Section 13 of this Supplement.

Current State Staffing

The legacy system has been operated and maintained by the Department of Commerce IT department which maintains approximately 5.5 Full-Time Equivalent resources, all of which have a systems development skill orientation. Offerors should not include use of these resources within their proposal.


of 118

2. General System Operation, Maintenance and Development Requirements

2.1. Development and Operations Conventions and Requirements

The Contractor is required to follow these guiding principles and requirements in the performance of the work contained in this SOW and any State approved changes arising from this RFP.

The State seeks to maintain, operate and enhance the State’s AX implementation to as close to “as delivered” Microsoft functionality and, as part of this work to the extent possible, avoid all customizations in lieu of “as delivered” Microsoft functionality under the following conventions (emphasis intentional):

No customization may introduce a systems performance issue, bottleneck or processing delay in consideration of the current operating state of the Commerce Liquor System. The current performance of the System, unless otherwise noted, shall be the performance baseline by which Contractor performance, system performance testing and State acceptance of same is measured. In the absence of performance statistics, Microsoft benchmarks of RTM code as made publicly available for key functions shall serve as the performance baseline.

No customization may invalidate, negate or minimize any warranty or maintenance requirement as agreed to between the State and Microsoft for AX, Windows, SQL Server and any other Microsoft provided system software elements that support the Liquor Management System.

No customization may be constructed in such a manner as to confound, add complexity to, or technically burden a future upgrade by the State to other versions of underlying Microsoft provided system software elements.

The State acknowledges that due to the nature of its business, and the various integration demands of a Statewide AX environment that certain existing customizations and extensions may still be required as a part of the implementation of future projects under this Supplement. Therefore, all RICEFW (Reports, Interfaces, Conversions, Extensions, Forms, and Workflows) objects must be designed, constructed, configured, and deployed that adhere to these conventions unless one of the following criteria are met (emphasis intentional) and agreed to in writing by the State upon consideration of the requirement, enterprise needs, cost/benefit and other factors:

The Contractor, as a first line of recourse, must advise the State on process, policy (and if applicable) revised code changes prior to the design and implementation of any customization. Further, all development efforts shall adhere to established Microsoft “best practices” coding conventions with regard to code structure, database access, documentation, commentary and other development metadata inclusive of programmer release notes, design documents, operational guides, index and SQL strategies and other modern code development documentation standards.

The Contractor shall analyze existing RICEFW customizations and objects, and for those identified as State specific with no viable alternatives, if still required by the State, the Contractor must obtain written State approval to continue these RICEFW customizations and objects as part of their Work.

For any new customizations that cannot be resolved as a result of alterations to State business processes, technical upgrade or other parts of the work described in this Supplement, contravene the aforementioned conventions and explicitly do not lend themselves to an “as delivered” or “configurable” approach, the Contractor must obtain written State approval to design, develop and implement these customizations prior to proceeding.


of 118

For the avoidance of doubt, the Contractor must not introduce any new customizations without written State approval. The Contractor must identify all existing customizations and seek to implement these customizations wherever possible as to use Microsoft delivered product code (i.e., AX, SQL Server or Windows operating system) in a supportable, upgradeable and State-wide consistent manner and seek State approval for the continuance of existing customizations.

Further, all developed and delivered customizations must perform, and be demonstrated to perform using production data volumes in a manner consistent with State operational use of the Microsoft AX platform.

2.2. State Infrastructure Obligations

The State will be responsible for providing the LMP infrastructure for this project to the Contractor. In general, this service includes the following:

Primary Computing Facility: State of Ohio Computing Center (secure Tier III capable facility)

Alternate/Disaster Recovery Center: Ohio Based Secure Tier II facility

Redundant Networking between State facilities and Data Centers (Metro-E to 10Gb/s OARnet)

Physical and Infrastructure Security Services

Redundant Power, Cooling, Fire Suppression and onsite Redundant UPS/Power Generation

Servers, Storage, Networking Devices, Firewalls, Security Appliances, Vulnerability and Virus Scanning to the operating system prompt

The State will provide ITIL based services in support of the Contractor as it directly pertains to the Work Areas and Services utilized by the Contractor in support of the State as follows:

State Infrastructure Responsibility Matrix

Asset Management Hardware Asset Tracking Software Asset Tracking Logistics Support Inventory Capture and Maintenance

Service Desk Help Desk Operations Help Desk Tools Service Desk Processes

Enterprise Security Management Emergency Response Service Threat Analysis Managed Intrusion/Detection/Prevention System Security Checking Security Advisory and Integrity Malware Defense Management Vulnerability Management ID Management Security Policy Management Security Compliance Support Security Audit

Server Management Platform Support (Tools/Processes Procedures) Unix/Intel Servers Incident Management Server Operations High Availability File Management

Storage Planning Capacity Management Storage Performance Management

Data Center and Wide Area LAN/WAN Management Enterprise Internet Services Regulatory/Change Management Network Engineering Standards LAN/WAN Management Network Operations and Management Network Capacity/Availability Management Network HW/SW Management Network Security Network M/A/C/D

Data Center Architecture Planning Hardware/Facilities Planning Unix/Intel Servers Platform Configuration Management Performance Management

Data Center Facilities Management Site Maintenance and Operations Site Availability Management Routine Maintenance and Upgrades


of 118

State Infrastructure Responsibility Matrix

Capacity Management Batch Operations/Scheduling Storage Management Backup/Restore (Service/Device) Media Management, Media Operations, Offsite Storage

The following items not be considered Contractor Fault with respect to Service level failures and therefore not apply to any Contractor Performance Credits or Overall Contract Performance considerations discussed later in this Supplement:

Failures outside of the scope of the Contractor responsibilities pursuant to the services responsibility matrix;

Failures due to non-performance of State retained responsibilities pursuant to the services responsibility scope;

Failure of an out-of-scope State provided element that directly impacts an in-scope Contractor element;

Failures arising from State provided equipment or networks;

A pre-existing or undocumented deficiency in a State provided computing element as they pertain to adhering to State Policies and Standards. In this case, upon identification the Contractor is to promptly notify the State of the identified deficiency.

Failure of a State provided resource to follow and comply with Contractor provided processes and procedures except where: (i) State Policies and Contractor policies are in conflict in which case the State resource shall notify the Contractor of the conflict and resolve which process applies or; (ii) in cases of emergency that would place the State resource in physical peril or harm;

Failure of a State provided third party warranty or maintenance agreement for in-scope services and infrastructure elements that result in the Contractor’s inability to perform at required levels;

The period of time associated with an incident where a State provided or contracted 3 rd party service, repair or replacement service renders an in-scope infrastructure element unusable by the Contractor to provide the Contracted Services shall be reduced from the overall duration timing of an incident;

The incident requires assistance for a State retained responsibility, is delayed at the State’s request, or requires availability of a user that is not available;

Mutually agreed upon service interruptions such as scheduled changes to the technical environment.

State implemented changes to Production Environments that the Contractor is not aware or apprised of.

2.3. Ownership and Licensing Considerations

Offerors are instructed to consider and address the following considerations with respect to software licensing for this RFP.

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., Dynamics, SQLServer, Windows, VMWare, existing toolsets);

Where software is proposed as part of this RFP which is required to 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


of 118

the agreement, offeror must 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;

Any hardware or cloud agreements purchased, loaned, leased or otherwise provided by the State to the Contractor in conjunction with the In-Scope Services shall remain the State’s sole ownership. The Contractor shall have no rights to the aforementioned hardware or cloud agreements. Hardware and Cloud agreements includes, but is not limited to: computing platforms, storage devices, tape and optical management systems, networking and telecommunications devices.


of 118

3. Systems Operations, Maintenance and Support Services (“Steady State Services”)

3.1. Project/System Change Management Support Services

The Contractor will be responsible for managing the overall delivery of the Services. The Contractor’s responsibilities with respect to Project/System Change Management include the following tasks, activities and responsibilities listed below, whether the Project is completed by the Contractor (under a Change Request or Statement of Work), the State independently or as a joint effort with the Contractor.

3.1.1. Program/Project Management Responsibilities: Support of Production Migrations

The State will:

Document data issues and provide to the Contractor, if such issues arise as a direct result of Contractor provided work, for resolution;

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 mutually agreed with the Contractor as appropriate;

Conduct post-Production Deployment quality and progress reviews with appropriate State and Contractor personnel;

The Contractor must:

Be responsible for the promotion of all code (Contractor delivered or otherwise) to State Production Environments including executing the production deployment and roll-out of any Release Package to the LMP Environment.

Be responsible for Production deployment including software deployment to the End User 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 Release Package software.

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

Execute required data conversions or migrations including, but not limited to, baseline system configuration tables and parameters, and ancillary supporting data as required by the system to function successfully in the production environment;

Establish data to be used with the new solution by producing new data and reconciling and mapping different data and database representations;

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

Document data issues and provide to the State, if such issues arise as a direct result of Contractor provided work, for resolution and provide a resolution for Contractor caused issues;


of 118

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 mutually agreed with the State as appropriate;

Compile and maintain solution issue lists;

Conduct Production Deployment quality and progress reviews with appropriate State and Contractor personnel;

Deliver and Support the State in the State’s implementation of changes to the State Production environment in a manner that is designed to help minimize disruption to the State business environment.

Support the State in controlled release methodology that includes version/code control, testing (functional, integration and performance) procedures inclusive of obtaining State approval(s) as mutually agreed.

Advise the State in the implementation release scope, quality, effort, schedule, budget, and resource risks or conflicts jointly with the State.

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

Develop and report business and technical risk and impact analyses in advance of any production implementation by the State.

Support the State in the development of post-production delivery analysis, documenting preferred experiences, and compiling recommendations for purposes of continuous service improvements.

Support general Project management principles by:

Using the State approved Project management tools (currently Microsoft® Project). Recommending, maintaining and updating a list of the Contractor’s work activities and Projects. Developing, maintaining and updating Project schedules. 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. Holding weekly status update meetings. Developing and providing to the State a status report summarized for all Projects.

Establish, review and enhance procedures by which the State may request enhancements, customizations, interfaces, modifications or other changes to each Contractor provided Project, Change or Enhancement.

During the first 90 days of production use, conduct a post-implementation review process upon the completion of a release which must include an analysis of how the business system(s) resulting from the Project compare to the post-deployment performance requirements established for such Project;

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

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


of 118

The Contractor must support the State in the establishment of 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 State technical team support required during the initial weeks of a production deployment as determined by, and mutually agreed with the State and must provide enhanced levels of support during the term of the Contract. Contractor must 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, if applicable.

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

3.2. State Application Help Desk Implementation and Ongoing Level 2 / 3 Help Desk Services

The State’s LMP Service Desk will provide the single point of contact (SPOC) for day-to-day communications between the State key personnel/IT staff and Application Administrators and end-users. Requests and incidents are reported by Users to the State Business and IT organizations 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 that pertain to State policy, process, procedures, implemented system functions, user support questions, common solutions and the like, the State Service Desk will provide immediate resolution, if not, then it will create an incident report which, depending on the nature of the issue, may require the support of the Contractor for resolution.

The current Agency and Warehouse facing (end-user) help desk utilizes a configured State instance of ServiceNow for Level 0, 1 and 2 functions. The State has no preference or bias against offerors utilizing this tool for functions within their scope. Offerors may utilize any internal help desk ticketing tool such that all requirements of this supplement, inclusive of service level agreements, are met. Configuration, operation and use of Contractor help desk tools are the sole responsibility of the Contractor. Additionally, the current code base (e.g., demo, design, non-production and production, defect management and resolution etc) are maintained by the State in Microsoft TFS, which will be the repository for all system code and configuration objects.

Incidents will initiate the appropriate chain of processes: Incident Management, Problem Management, Change Management, Release Management and Configuration Management. This chain of processes will be tracked using the State’s trouble ticketing system, which records the execution of each process, quality control point, and store the associated output documents for traceability.

The following classification responsibility matrix shall be utilized by the State and Contractor in consideration of level 2 and level 3 help desk services:

Help Desk Level / Support Tier Representative Functions Responsibility

Level 0 Customer “Self Help”: routine password resets, common issues, FAQ, Job-Aids etc End-User

Level 1 State Specific, routine, Policy, Process, Procedure, Routine Business or Transactional Processing matters that require user support, but no input or support from the Contractor State - State

Level 2: Business Issues

State Specific, complex Policy, Process, Procedure, Routine Business or Transactional Processing matters that require user support, but advisory or consultative support from the Contractor, but nonetheless do not require remediation (e.g., code, configuration or

State – State, limited/advisory


of 118

Help Desk Level / Support Tier Representative Functions Responsibility

alteration to the State operational software base) support of Contractor

Level 2: Software or Solution Issues

Those issues arising from the aforementioned levels that require the direct involvement of the Contractor due to their complexity and potential impacts to code, configuration, job schedules, interfaces and/or reports

Contractor, with State Support

Level 3: Software / Solution Issues, all Severity 1 or 2 Defects or Outages

Those issues arising from the aforementioned levels that require the direct involvement of the Contractor due to their complexity and potential impacts to code, configuration, job schedules, interfaces and/or reports. Issues involving any combination of Contractor Provided Software, State Infrastructure and/or 3rd Party Elements (e.g., databases, operating systems, job schedulers, integration software and the like)

Contractor, with State Support

3.2.1. Establish an Application Service Management Desk Capability with the State

The State requires that the Contractor assist the State in the design and deployment of a comprehensive service desk that aligns with the successful support of end-users, State trading partners, State users and the State systems operations and technical community as to follow principles which will support the State’s general use of Information Technology Infrastructure Library (ITIL®) service delivery conventions.

The Contractor will jointly design and deliver services via a set of ITIL® v3 concepts and techniques for operating and managing the LMP environment.

The State LMP Service delivery team and related Business Unit functions are familiar with, and in many cases have been trained on ITIL principles and processes. Therefore, the Contractor is not required to provide general ITIL training as part of their responsibilities.

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, Operations Management, Application Management, and IT Services Continuity Management for Levels 0-3 for LMP; and leverage Contractor services as previously described pertaining to Levels 2 and 3.

Incident Management process and procedures must 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. 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;

Processes and procedures are to include:

Incident detection and recording;

Classification and initial support;

Investigation and diagnosis;


of 118

Resolution and recovery;

Incident closure; and

Incident ownership, monitoring, tracking and communication.

Problem Management processes will be utilized to identify record, track, correct and manage problems impacting LMP service delivery. It will be implemented to assist the State in recognizing recurring problems, addressing procedural incidents and containing or minimizing the impact of problems that occur. The Contractor must implement and follow Problem Management processes 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. The requirements of the Problem Management process are:

Reduce the number and severity of incidents and problems on the business, and report it in documentation to be available for Level 1 and 2 (State operated functions) and Level 2 and 3 (Contractor operated functions) as well as hand-off to State Infrastructure (State Provided) Service Desk; and

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

Processes and procedures are to 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.

Operational Services processes must be implemented and followed that define the daily activities to deliver service from the use of LMP applications, software and services in order to meet Service Level Agreements and established business targets for the LMP environment within the Contractor’s scope. This collection of processes must be designed to adapt and respond 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 LMP. This includes managing contact with Users. Services include database and application management, event management, incident management, problem management and service execution.

3.2.2. Support Level 2 and Level 3 Application Problems, Issues and Changes

For each incident escalated to the Contractor by the State that the State cannot resolve without the involvement of the Contractor, the Contractor must:

Handle incidents and requests through full life cycle management of all service requests as set forth in the Run Book or other supporting operational documents.


of 118

Provide a Single Point of Contact for entry and exit to the service process and providing an interface for 3rd Parties essential to the service processes.

Provide ease of use and a good customer experience for the State Users.

Maintain security and assuring data integrity as required for the successful operation and maintenance of the system.

Provide timely and effective communication which keeps the State Business and IT Users informed of progress and of appropriate advice on workarounds.

Contractor responsibilities further include:

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

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

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

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

The State will:

Ensure end-users have a basic level of understanding of the State and Contractor established Service Delivery processes and adhere to such processes for accessing the Services;

Be responsible for all end-user training on how to utilize the State service desk and escalation procedures to progressively higher levels (i.e., 2 and 3) that require the support of the Contractor;

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

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 issue prioritization guidelines and escalation procedures;

Communicate support responsibilities and procedures to the State Single Point of Contact and 3rd 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 and associated Service Level commitment, in the resolution of recurring problems which are the result of user error;

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

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


of 118

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

3.2.3. Level 2 / 3 Ticket Volumetric Requirements

The State and Contractor will review the ticket load presented to and resolved by the Contractor to mutually refine develop a Level 2 and 3 help desk staffing model, by service delivery area. This review will include actual ticket volumes flowing from the State retained Level 1 and (business) Level 2 help desk to the Contractor following an agreed upon stabilization period, commencing no less than 90 days following the completion of the migration of services to the Contractor’s Service Delivery Center.

The State and Contractor agree to meet to review the actual ticket volume passed from State retained functions to the Contractor’s Level 2 and 3 help desks. In the event that ticket volumes are materially different (i.e., more than 10% higher or lower in aggregate over the period than anticipated) the Contractor agrees to provide additional resources or reduce resources, or change the mix of resource skillsets to meet any revised ticket level and will provide pricing associated with these resources utilizing the prevailing unitized pricing in effect at the time the difference is detected and agreed to by the State. It is recognized that the Contractor's Help Desk staffing is driven both by the Level 2/3 ticket volumes as well as the skill set mix required to process the varying types of tickets that could be processed. Notwithstanding the foregoing, no elements of the Contracted service outside of this Section 3.2 shall be subject to Ticket-based variations.

3.2.4. Annual Contractor Level 2 / 3 Ticket Reviews and Adjustments

Thereafter, on an annual basis, commencing with the first anniversary of the agreement, the State and Contractor will meet to review historical averages, methods to reduce help desk ticket volumes through continuous improvement, technology and efficiency advancements, training or otherwise. Based on the anticipated needs and in consideration of the aggregate ticket volume in the preceding six (6) months exceeding a 10% threshold (either up or down) the State and the Contractor will establish the appropriate Level 2 and 3 staffing level for the next year of service. In any event, if ticket volumes fall within the 10% range in aggregate, no changes to the staffing level shall be in effect, although changes to staff skill mix may be requested, and in no case shall relief be provided to the Contractor as a result of failing to meet established Service Levels as defined in this RFP. Ticket volume changes and skill set mix based on the complexity of presented tickets from the State to the Contractor shall be the determinants of increases and decreases to the Contractor’s staffing model for Level 2 and 3 help desk functions.

Contractor responsibilities 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 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 Dynamics and Microsoft Support, including contact phone numbers; and


of 118

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

The State will:

Be responsible for all end-user training;

For in-scope State-retained systems, provide systems status information to the Contractor Service Desk and updates as they occur. The Contractor must maintain such information as set forth in the Run Book or other supporting documents;

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 State and Contractor established 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 3rd 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 timeframe 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 of the State 3rd Party service provider performance problems affecting the Contractor's provision of the Services;

Be responsible for all the State 3rd 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 Contractor’s scope Services.

Notwithstanding the foregoing, no elements of the Contracted service outside of this Section 3.2 shall be subject to Ticket-based variations.

3.2.5. Initial Ticket Volumetrics: Offeror Sizing Guidance

The State advises that as this Managed Service will be new to the State, no reliable ticket information is available for LMP system as part of the initial go-live of the Service.

For sizing purposes only, offerors are instructed to design, staff and price their solution based on the following estimates. The State and Contractor will review actual sizing at ninety (90) days following the introduction of the Service and formulate a mutually agreeable adjustment (up or down) at this ninety (90) day mark under the provisions of the preceding section in light of actual ticket volumes presented to the Contractor via the Level 2 / 3 help desk that in adherence with SLA requirements that represent a steady-state baseline following the stabilization of the Run Service.

Level 2 / 3 Contractor Initial Sizing Requirements (Monthly)


of 118

Help Desk Tier State LMP Application

Level 1(Login/Password, FAQ, State Devices, Navigation etc) Issues/Questions

State Managed, Out of Contractor ScopeState experience is that 80% of all requests

are addressed by this Tier

Level 2 (Business) Business Process, Policy, Reporting, Devices, Integration, Routine Business Questions (State internal, Stakeholder and Agency)

State Managed, Out of Contractor ScopeState experience is that 10% of all requests

are addressed by this Tier

Level 2 (Application and Operations)(Application, Integration, Reporting, Job Scheduling etc) Contractor Escalated Issues

200

Level 3 (LMP, AX, Integration, Performance, Data, State Developed Code, Infrastructure, Database etc) Issues 20

Total Contractor Level 2 / 3 Monthly Tickets (Initial Sizing) 220

The State does not maintain volumetric information (sizing and resolution times and the like) for the system at this time due to its current stage of development and degree of support provided by system integrators performing projects. The aforementioned values are for initial sizing and quotation purposes only and are subject to change.

3.3. Environment Review and Advisory Services

The Contractor, in the course of supporting the State under this Work Area, no less frequently than quarterly, must:

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.

Assist the State in monitoring and analysis of trends to identify potential issues and follow-up on recurring problems.

Collaborate with State production staff, to manage and optimize production schedules.

Monitor operations for correctness and adherence to agreed quality, performance and availability criteria as set forth in the Run Book or other supporting documents.

Assist the State in batch monitoring and restart, should the State be unable to diagnose or remedy recurring production issues including batch jobs start, run-times, conflicts and abnormal termination conditions

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

3.4. Problem Management Support 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.


of 118

Contractor responsibilities further 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.

3.5. Release and Configuration Management Requirements

Release and Configuration Management processes will be implemented and followed for designing, planning and maintaining the physical and logical configuration of LMP Systems software as well as 3 rd Party components and the way these resources are interrelated in the State LMP environment. The Contractor must employ ITIL based processes and tools that track all configuration Items in the LMP service catalog for the supported LMP software and service elements.

Release and Configuration Management Processes and procedures must include:

Planning: The Configuration Management plan must cover the next six months in detail, and the following twelve months in outline. It is reviewed with the State at least quarterly and include strategy, policy, scope, objectives, roles and responsibilities, the Configuration Management processes, activities and procedures, the database, relationships with other processes and 3 rd Parties, as well as tools and other resource requirements.

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.

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

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.

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.

As configuration management (depending on the nature of the configuration changes) could be a complex and highly dependent work area, the State and Contractor agree to the following roles/responsibilities pertaining to Configuration Management Services:

Release / Configuration Management Scope Considerations / Criterion Responsibility

Simple Configuration Modify/Enhance Applications with Simple Configuration. No Code Changes Required State


of 118

Release / Configuration Management Scope Considerations / Criterion Responsibility

Changes

Moderate Configuration Changes

Modify/Enhance Applications with Simple Configurations that may be nested or have multi-configuration change dependencies. No Code Changes Required Contractor

Complex Configuration Changes

Modify/Enhance Applications with Configurations that may be nested or have multi-configuration change dependencies. Code Changes potentially required or need careful consideration as to not adversely impact system functions or operations.

Contractor

Highly Complex Configuration Changes

Modify/Enhance Applications with Configurations that may be nested or have multi-configuration change dependencies. Code Changes required to successfully affect configuration changes and minimize/eliminate adverse system functions or operations.

Contractor

Complex Customizations, Code-Based Customizations

All other Customizations that Require Alteration of Delivered/Current Code. Contractor

3.6. Break/Fix Services


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 inclusive of code, database, integrations, reports, workflows forms and other elements as provided by the Contractor to the State;

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;

Independently test configuration changes to confirm resolution of defects;

Identify, specify and system test (following State installation) 3rd Party supplied patches, security updates, feature packs and fixes for 3rd Party 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;

Identify to the State any issues that may 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 functional, integration or technical issues with in-scope environments or operations and incorporate resulting changes into ongoing continuous improvement initiatives;

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

Ensure compliance 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 and report to the State in writing any risks or issues that the Contractor becomes aware of in providing Service to the State. For example: patches designed to address immediate or active Security issues may be scheduled for a near-


of 118

real-time release, where other less pressing releases may be implemented during a scheduled maintenance or outage period;

Follow a mutually agreed, formalized and published methodology in providing complete systems, environments, configurations and Contractor supplied technology elements from development and testing environments to the State for onward application by the State to State production environments; and

Implement all State approved changes, to be provided by the State in writing, to State production environments upon ensuring that the then current production environment is sufficiently backed up and restorable to the pre-change configuration (in its entirety) as to “roll-back” to this prior version should a change to State production environment result in unanticipated or unacceptable business outcomes.

3.6.1. Emergency Break / Fix Support

In the case of an emergency condition declared by the State, or requested by the State CIO or designate pertaining to a system incident, problem or outage, and in keeping with State security policies in effect, the Contractor may be requested to 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 must promptly notify the State of all such temporary System Environment Changes.

At the conclusion of the emergency condition, the Contractor must 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 must be initiated for State review and approval.

3.7. Environment Management (Production, Non-Production, QA, Projects, Demo/Train, Test)


Perform environment/supported 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.

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 must install Systems software upgrades and enhancement for versions (i.e. X.1, where X is the version) as a Project approved by the State.


of 118

Support the various service tiers (i.e., 24x7, Published Hours less Scheduled Downtime, Business Hours) 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 as to verify batch jobs start as scheduled; are monitored to adhere scheduled run length parameters; reschedule or restart failed jobs following remediation of issues that caused run failures or run length issues and 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.

3.8. System Backup, Backup Validation and Restoration Requirements

The State, DAS/OIT as an enterprise service to all Agencies, provides centralized “virtual tape library” (VLT) services. The LMP has been configured to perform backup and restoration services using the OIT VLT service.

The Contractor must perform backup processes as follows:

Type Description Scheduled Frequency and Timing Retention Period

Baseline Pre-production image Once, at service commencement Until first annual + 1 month

Daily Incremental Files Data changes during the period Daily 6 Days

Full Data Files All resident data files Weekly (weekend) 4 Weeks

Applications All application files Monthly and Immediately preceding and following any updates to application software 4 Weeks

Pre-Production Initiations

All initiation files during the Production introduction/implementation period Daily 6 Days

Operating System and Related Infrastructure

All O/S configuration files and related Infrastructure software

Monthly 12 Months


of 118

Type Description Scheduled Frequency and Timing Retention Period

software

Database All Database Weekly (weekend) 12 Months

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

As needed 4 Weeks, unless otherwise required

3.9. System Environment and Service Architecture, Standards and Advisory Services

Contractor’s responsibilities with respect to the System Environment and Service Architecture, Standards Services must include the following:

Support of the State in specifying Virtual machine and end-to-end LMP Environment provisioning requirements. Provide all associated setup, configuration and maintenance parameters and configuration elements per manufacturer, Contractor best practices or recommended specifications.

Validate State configuration of physical and virtual machines, State infrastructure elements (e.g., Storage, Network, Job Schedulers and Ancillary Devices and Software, Security Elements).

Establishment of global LMP system policies, procedures, base configuration data, data management (e.g., archive, backup and purge) and technical operating procedures as to help ensure that the State provided technical elements align with, fully support and do not conflict or contradict with Contractor required or recommended capacity, performance, versioning and other elements as required for the State to successfully operate and maintain the system.

Perform database and configuration value load(s) from required environment sources (e.g., production, non-production) coincident with any system change arising from a major or minor upgrade, system release, patch, security update, or introduction of State infrastructure elements.

Validate that the environment is useable for its intended purpose and operating within established performance, functional and quality baselines.

Develop, and thereafter maintain an end-to-end data architecture that reflects the then current system inclusive of logical and physical data models, process and interface architectures, reporting database(s) and summarization data and job schedulers/job performance.

Regularly (no less frequently than quarterly) review the system for opportunities to increase data quality, data management processes, interface performance (timeliness and automation), report and scheduled job performance and exchange of data with external State trading partners.

3.10. User Management and Administration

The State will retain responsibility for the management and responsibility for all security functions related to the Systems software including user, State, and administrative access and passwords (i.e., users with root, admin, administrator, DBA or low-level read/write access) and the related security controls to maintain the integrity of the Systems software, based on the Contractor’s standard service center security processes.

The Contractor, should the State request assistance, will provide advisory services in best practices pertaining to security role, permissions, privileges, access grant/revocation methods, establishment of common security templates as to programmatically administer (i.e., establish, change, delete or modify) such elements that comprise the State’s User Management and Administration functions for LMP.


of 118

3.11. Software Product Evolution and Roadmap Planning/Advisory Services

The Contractor must, no less frequently than annually, sponsor a planning session to review upcoming releases, enhancements, upgrades, major/minor releases, patches and service packs that: either have been available to other customers who use the system in a similar manner as to the State or are planned for the upcoming year (or if applicable, multi-years) and:

Discuss the merits and applicability for use by the State, as well as discussions as to the timing, impact, level of effort and other factors that may be required for the State to consider as part of its LMP system release roadmap;

Include in this discussion a listing of all State required or suggested system enhancements and upgrades and the disposition (e.g., timing, level of effort, impact etc.) of such State required or suggested system enhancements;

Identify (within the State’s environment) configuration data, customizations, integrations and reports that – in the context of a future release are rendered redundant, obsolete, incompatible or otherwise not required in lieu of superior methods available in a future release that achieve the State’s business requirements or (in the case that the methods are not acceptable or applicable to the State) may require the State to consider not deploying such items to the State’s environment.

Incorporate evolutions in technology that will improve the State’s use, operation and maintenance of the LMP system with respect to hardware, software, databases, ancillary elements (e.g., integration, job scheduling, reporting, etc.), security, performance and other factors as to ensure that:

1. The System maintains the proper configuration/version levels as to maintain OEM support for all hardware and software elements required to operate and maintain the system (e.g., operating systems, underlying hardware, database versions, integration software etc)

2. Incompatibilities are identified to the State such that the State can anticipate, as part of the State’s overall planning process, change, upgrades or replacements to State provided elements in advance of such incompatibilities arising;

Finally, work with the State and other State vendors associated with providing peripheral or ancillary technology in support of the State’s environment (e.g., document management systems, identity/access management software, payment/claims gateways, security software providers and the like) to review and discuss with the State (and these vendors if applicable) the merits, challenges, limitations and impacts to the LMP environment as it relates to such elements used by the State, or under State consideration for adoption.

3.12. System and Performance Testing / Validation

As part of any scheduled release whether major or minor, functional, technical, interface, integration or other change, the Contractor must support the State (upon State request) to perform System and Performance Testing. This service must include:

Comparisons of system element functionality to mutually agreed upon testing expected results.

Demonstrating via reports, data or system use, compliance with mutually agreed upon expected results.

Reviewing successful test completion reports with the State prior to the State performing any Acceptance Testing or Production deployment.


of 118

Comparisons of performance results against those results obtained during any system development lifecycle pre-production tests.

Comparisons of performance results to the then current performance baselines to ensure that operational and technical performance characteristics adhere to mutually agreeable norms.

State acceptance documents that demonstrate that the State is in acceptance of any system change to the supported system(s).

3.13. Program Management & Master Release Calendar

The Contractor, in consultation with the State will: develop, and thereafter maintain and publish on a monthly basis a Master Release Calendar that includes a schedule (with dates) of:

Major Scheduled Releases, Upgrades, Updates and Enhancements

Implementation of Minor Enhancements or Discretionary Work

Scheduled Maintenance Windows and Planned Outages

Infrastructure Related Upgrades, Updates, Patches and Enhancements

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

Major Processing Events as contained in the Run Book

Audit and SSAE-16 Key Dates

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

3.14. Disaster Recovery Planning Support and Implementation

The Contractor must collaborate with the State to support the State’s development of a Disaster Recovery Plan for LMP. The Disaster Recovery Plan must document the sequence of events to follow in the circumstance that an internal or external interruption impacts Services provided to the LMP user community that may arise as a result of failure of one of more elements that comprise the LMP infrastructure, hardware, software, interfaces, networks, State data center facility, power and the like.

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

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 State and Contractor.

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

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


of 118

3.14.1. Disaster Recovery Planning Support Services

To the extent agreed appropriate, participating in planning sessions, testing review sessions and other meeting activities during the term of the Contract, the Contractor will support the State’s implementation of disaster recovery plans as agreed based upon the following principles:

Utilize the State’s provided 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 the State provided disaster site must occur within 24 hours of failure of primary site

Transfer of the State data, configuration and user access to this site must occur within 24 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

Utilizing the State’s provision of redundant processing hardware to ensure 24x7 operations

Utilizing the State’s provision of redundant networking (network devices and telecommunications access) to ensure 24x7 operations

Ensure that Contractor provided software elements, configuration and transactional data, interfaces, reports, customizations/extensions and ancillary items are in fact included and addressed by the State’s Disaster Recovery plan as to affect the orderly restart of the system in the State’s Disaster Recovery Site, and following the cessation of the Disaster, resume operation in the State’s primary data center.

3.14.2. Support of Annual Disaster Recovery Rehearsal and Testing

The Contractor must support the State in the establishment joint test objectives with the State designed to verify that the LMP must be available within the agreed upon timeframes contained in the mutually agreed disaster and business continuity plan.

The Contractor must participate in the scheduling, rehearsals and testing of components of the disaster recovery and business continuity plans relating to the in-scope Applications at least annually in support of the State, its designees, any testing and recovery providers and relevant State Third Party Contractors no less frequently than annually.

The Contractor must provide commentary to the State to the effect that all disaster recovery services are designed and implemented to allow for the State to continue to operate and manage the system during periodic disaster recovery tests.

The Contractor must notify the State as soon as practicable upon becoming aware of a disaster affecting the Services.

The State must coordinate with the Contractor to support the mutually agreed disaster recovery and business continuity plan. In such regard, Contractor must:


of 118

Validate 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 State in accordance with the procedures set forth in the engagement practices and relevant Statements of Work;

Support the State to support the reinstatement of the in-scope Applications at such backup location; and

Maintain an inventory of errors, gaps and omissions witnessed by the Contractor as they relate to the State’s provision of the Services for unaffected areas.

Following any disaster, in consultation with the State, the Contractor must support the State in the 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 or test, the Contractor must participate in 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, the Contractor must maintain compliance with the disaster recovery policies, standards, and procedures contained in the State disaster recovery and business continuity plan.

During annual test the Contractor must, provide documented results, remediation and feedback procedures contained in the State disaster recovery and business continuity plan and allow for State participation and review of the testing process.

3.15. Legal/Regulatory and Minor Change Requirements

Based on the State’s experience with the management and ongoing operations of the LMP environments, the State is requiring the Contractor to provide services to address minor alterations or enhancements (generally less than 100 hours per occurrence inclusive of analysis, design, construction, testing and implementation tasks or otherwise agreed) to Applications within the scope of the Contractor Services that arise as a result of legal, regulatory, mandates or changes to the State’s business. 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 such services in order to maximize personnel continuity.

The Contractor must include, in their proposed annual cost for Services, an initial pool of four thousand (4,000) hours to be used in conjunction with the Contractor’s Rate Card, and represent an initial minimal monthly staffing level of two (2) full-time personnel equivalents. 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 each fiscal year of Contract execution to review this discretionary hour pool and make adjustments as required. In the event that the discretionary hour pool is adjusted, the State and Contractor will work to establish an annual number of hours, and base staffing level commitment for each year of the agreement.

The Contractor must provide a schedule of Legal/Regulatory and Minor Change hours consumed (by activity, resource and Project) and a forecast of remaining hours and activities to the State on a monthly basis.

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


of 118

Ad-hoc requests require limited-to-no modification of code, complex configuration activities, or customization of reports, interfaces, workflows, forms associated with system environments.

Such requests may additionally include the investigation of recurring, intermittent or unforeseen processing situations that require deep investigation of the system coincident with an incident, problem or change to the system.

The Contractor must 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 2 Service Desk to effectively manage demand.

Routine tracking procedures must 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.

3.16. Maintaining Solution and Operations Documentation


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 3 rd 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 errors or obsolescence), and such inaccuracy may negatively affect the Services, Contractor must correct such documentation as part of normal day-to-day operational support.

Update programmer, End-User and operational reference materials, procedures, job-aids and support documents as to incorporate all releases of the system and be reflective of the then-current LMP operating environment.

Provide and maintain an end-to-end data architecture that reflects the then current system inclusive of logical and physical data models, process and interface architectures, reporting database(s) and summarization data and job schedulers/job performance.

Maintain all documentation on the State’s SharePoint site and ensure that all documentation is current following any change to the Service or LMP as it relates to documentation and conduct an annual audit for State review of all documentation to ensure ongoing compliance with these requirements.

3.17. Annual Technology, Infrastructure Optimization: Planning and Updates

The Contractor must create a comprehensive technology and process optimization plan, and updates to the plan no less frequently than annually that is aligned with industry or vendor specific best practices and in keeping with the achievement of Service Level Agreements (SLAs) contained in this Work Area. Based on the review and approval by the State, this plan will be jointly implemented by the State and Contractor within their respective responsibility areas as part of the Services on an ongoing basis. Based on Contractor best practices, and in keeping with the 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):


of 118

Refinement of existing hardware capacities, configurations, environments, job schedules and operational processes to ensure overall continuity and minimization of operational disruptions or diminishment in service due to system obsolescence or opportunities to optimize the LMP platform and how it operates;

Phased replacement or enhancements to operational and technical processes over the term of the Contract to best leverage existing State investment in technology components, use of personnel (both State and Contractor) while minimizing any disruptions in service associated with the implementation of the operational or technical processes.

In any case, the Contractor is specifically required, as part of the technology optimization plan to: adjust processing, configuration, job schedules or operating processes/procedures to leverage the State’s investment in the LMP infrastructure and software while minimizing manual labor, work/re-work cycles, non-productive endeavors or other elements that would allow the State to operate LMP in a more optimal fashion.

The State has invested significant capital and operating expense in the creation and ongoing operation of LMP since it was conceived. As a result of ongoing LMP deployments, stabilization and evolution and business operation enhancement opportunities to leverage LMP in support of State’s mission.

Retirement of Legacy State applications or processes where LMP provides identical or similar functional footprints;

Continued refinement of the Business Analysis, Reporting and Intelligence capabilities within the State; and

Enhancements to the overall Planning and Budgeting Process that effects all businesses in the State in some form; other opportunities that may arise based on Executive, Administrative and Stakeholder level priorities.

To support the LMP organization in the identification, development and evaluation of these opportunities, the Contractor must support State in:

The development and refinement of ongoing Business Roadmaps;

Creation of business case, change programs and LMP enhancement/upgrade/optimization budgets, timelines and investment models that are pragmatic and grounded in the realities of budgets, implementation efforts and LMP capabilities;

Support of updates to State’s business processes and associated user training materials, job aids, FAQs and other end-user assistance materials to utilize new or changed features and functions associated with a system release, enhancement or upgrade.

Development and delivery of exploratory workshops with new LMP customer groups from the above, including showcasing emerging technology elements, technology evolutions, and new features and functions;

Leading of “change agent” type communications designed to encourage refinement and optimization of LMP service offerings

Support State management in bridging: business, functional and technical and organizational changes to propose, design, implement and extend State LMP-based functions Statewide.

Ensure that the State LMP asset remains relevant, contemporary and supported over its useful life.


of 118

To this end, the Contractor must support the State in the aforementioned functions and (when requested) provide input into capital and operating budgets, business cases, budget elements as to support the State in multi-year planning and budgeting exercises.


of 118

4. Steady State Run Services – Service Level AgreementsThe State is committed to providing high quality, responsive, reliable and contemporary Services to State systems, internal State users and, importantly businesses and citizens that interact with the State via its Systems and Services portfolio.

The Contractor must regularly review the current environment inclusive of hardware, network, software, infrastructure, security, back-up and other ancillary technical components that comprise LMP no less frequently than quarterly and maintain a plan with the State. as part of the State’s overall operational responsibility for the existing environments to ensure that service levels, operational performance, technical capacity and personnel (both State and Contractor) efforts are aligned with providing the State a high level of service value, operational reliability and stability as well as best use of the resources that comprise and operate LMP.

4.1. Scope Considerations as they relate to Service Levels and Contractors Supporting of the State

The following items are not be considered Contractor Fault with respect to Service level failures and therefore do not apply to any Contractor Performance Credits or Overall Contract Performance considerations discussed later in this section:

Failures outside of the scope of the Contractor responsibilities pursuant to the Services responsibility scope;

Failures due to non-performance of State retained responsibilities pursuant to the services responsibility scope;

Failure of an out-of-scope State provided element that directly impacts an in-scope Contractor element;

Failures arising from State provided equipment or networks;

A pre-existing or undocumented deficiency in a State provided computing element as they pertain to adhering to State Policies and Standards. In this case, upon identification the Contractor must promptly notify the State of the identified deficiency.

Failure of a State provided resource to follow and comply with Contractor provided processes and procedures except where: (i) State Policies and Contractor policies are in conflict in which case the State resource must notify the Contractor of the conflict and resolve which process applies or; (ii) in cases of emergency that would place the State resource in physical peril or harm;

Failure of a State provided third party warranty or maintenance agreement to deliver services to the Contractor for in-scope services and infrastructure elements that result in the Contractor’s inability to perform at required levels;

The period of time associated with an incident where a State provided or contracted 3 rd party service, repair or replacement service renders an in-scope infrastructure element unusable by the Contractor to provide the Contracted Services can be reduced from the overall duration timing of an incident;

The incident requires assistance for a State retained responsibility, is delayed at the State’s request, or requires availability of an End User that is not available;

Mutually agreed upon service interruptions such as scheduled changes to the technical environment.

State implemented changes to Production Environments that the Contractor is not aware or apprised of.


of 118

4.1.1. Treatment of Federal, State, and Local Fines Related to Service Disruption

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 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.

4.2. Service Level Specific Performance Credits

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

A financial credit will be due to the State (a “Performance Credit”) in the event a specific Individual 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.

The State believes, based on operating several very large scale systems under services agreements with a variety of leading industry vendors, that these SLAs are aligned with the market, achievable under reasonable Contractor scope and effort considerations, and are specific, measurable and actionable for both the State and Contractor to measure performance and seek corrective actions. The State has chosen these levels in to be realistic and does not have the view that “generally green” future performance for a period of time does not excuse Contractor deficiencies that result in a red or yellow condition that impacts under a past operating condition State operations or service quality. Therefore No Contractor recovery or “earn-backs” are permitted under this agreement.

Fee credits will be calculated as follows:

Any Service Level in a Reporting Month that results in a Yellow Status will result in a Contractor Performance Credit of 1% of the Monthly Service Charges; and

Any Service Level in a Reporting Month that results in a Red Status will result in a Contractor Performance Credit of 2% of the Monthly Service Charges.

The Contractor will not be required to provide Performance Credits for multiple Performance Specifications for the same event or incident, with the highest Performance Credit available to the State for that particular event to be applicable. For the avoidance of doubt, a single incident or event that may impact multiple SLA categories will only be calculated on a single SLA category that is most applicable to the incident or event and not multiple categories.

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 on the next scheduled or presented Contractor invoice to the State.

Moreover, in the event of consecutive failures to meet the Service Levels, the Contractor will be required to credit the State the maximum Credit under the terms of this document.


of 118

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.

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

4.3. Period Service Level in Full Effect and In-Progress Service Levels

Service levels specified herein shall be in full effect no later than ninety (90) days following the commencement of Services within this Section 4. During the phases in which the Contractor is implementing the Services and while the State project team still retains operational responsibility of the application environments, the Contractor will not be subject to financial credits associated with the Service levels described herein, but nonetheless are required to report the service levels as specified. During the period in which the State and project team no longer have substantive operational responsibilities pertaining to the application environments, and the Contractor is operating application environments for the State, or a combination of State and Contractor responsibilities the Contractor agrees to:

1. Perform services in keeping with the described Service Levels contained herein;

2. Promptly report any Service Level violations in accordance with the Service Level reporting requirements contained herein;

3. Work in good faith and using commercially reasonable efforts to address and otherwise resolve service level violations that arise;

4. Provide a level of service in keeping with levels performed by State personnel and otherwise aligned with commercial best practices prior to the operational transfer; and

5. Not be subject to any financial credits associated with Service Level violations.

Due to the nature of the implementation of future Major Projects or new modules associated with LMP, full SLAs will not be in effect for the these applications until such time as either module is moved to a production environment or is used for commercial use, whichever is sooner. During a period of ninety (90) calendar days immediately following a production migration or commercial use, or an alternative period otherwise agreed by the State, the acceptable performance during this stabilization period will be no less than a “yellow” status and financial credits will not apply unless the Major Project or module is deemed to be performing in a RED state.

4.4. LMP System Steady State Support Services: Service Level Requirements

Contractor will meet the Service Level Commitment for each Service Level set forth in the table below and specified in detail later in this section.

Service Level Coverage

1 Incident Resolution – Mean Time to Repair (Severity 1 Issues) 7x24

2 Incident Resolution – Mean Time to Repair (Severity 2 Issues) 7x24

3 Incident Resolution – Mean Time to Repair (Severity 3 Issues) State Published Business Hours


of 118

Service Level Coverage

4 Production Release Management – Successful Deployment to Production 7x24

5 Incident Resolution - Issue Triage, Closure and Recidivist Rate State Published Business Hours

6 Job Schedule and Scheduled Reporting Performance Scheduled Hours

7 Service Quality – System Changes Scheduled Maintenance Periods

8 Help Desk Services – Responsiveness and Closure Rate State Published Business Hours


of 118

4.4.1. Incident Resolution – Mean Time to Repair (Severity 1 Issues)

Business Intent: Prompt resolution of LMP and Application issues that impact State processing and processes

Definition: Mean Time to Repair (Severity 1 Issues) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Severity 1 Issue Service Requests for in-scope Services in the Contract Month. “Time to Repair” is measured from time Service Request is received at the Contractor 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. “Severity 1 Issue” is defined as :

An Incident shall be categorized as a “Severity 1 Issue” if the Incident is characterized by the following attributes: the Incident (a) renders a business critical System, Service, Software, Equipment or network component un-available, substantially un-Available or seriously impacts normal business operations, in each case prohibiting the execution of productive work, and (b) affects either (i) a group or groups of people, or (ii) a single individual performing a critical business function.

This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan.The Contractor will report updates and progress to the State every thirty (30) minutes for this SLA until resolved in the impacted environment(s).

Formula: Mean Time to Repair (Severity 1 Issues) =

Total elapsed time it takes to repair Severity 1 Issue Service Requests

Total Severity 1 Issue Service Requests

Measurement Period: Reporting Month

Data Source: Monthly Service Report

Frequency of Collection: Per incident

Service Level Measures:

Individual SL GYR State Mean Time to Repair (Severity 1 Issues).Green <= 4 hoursYellow > 4 hours and <= 6 hours

Red > 6 hours


of 118


Business Intent: Prompt resolution of LMP and Application Issues that impact State processing and processes

Definition: Mean Time to Repair (Severity 2 Issues) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Severity 2 Issue Service Requests for in-scope Services in the Contract Month. “Time to Repair” is measured from time Service Request is received at the Contractor 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. “Severity 2 Issue” is defined as : An Incident shall be categorized as a “Severity 2 Issue” if the Incident is characterized by the following attributes: the Incident (a) does not render a business critical System, Service, Software, Equipment or network component un-Available or substantially un-Available, but a function or functions are not Available, substantially Available or functioning as they should, in each case prohibiting the execution of productive work, and (b) affects either (i) a group or groups of people, or (ii) a single individual performing a critical business function.This Service Level begins upon completion of agreed production acceptance criteria and a measurement period as documented in the transition to production plan.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.The Contractor will report updates and progress to the State every sixty (60) minutes for this SLA until resolved in the impacted environment(s).


Total elapsed time it takes to repair Severity 2 Issue Service Requests






Individual SL GYR State Mean Time to Repair (Severity 2 Issues).Green <= 8 hoursYellow > 8 hours and <= 12 hours

Red > 12 hours


of 118


Business Intent: Prompt resolution of LMP and Application issues and irregularities that impact State processing and processes

Definition: Mean Time to Repair (Severity 3 Issues) will be determined by determining the elapsed time (stated in hours and minutes) representing the statistical mean for all Severity 3 Issue Service Requests in the Contract Month. “Time to Repair” is measured from time a Service Request for in-scope Services is received at the Contractor 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. “Severity 3 Issue” Is defined as:An Incident shall be categorized as a “Severity 3 Issue” if the Incident is characterized by the following attributes: the Incident causes a group or individual to experience a Incident with accessing or using a System, Service, Software, Equipment or network component or a key feature thereof and a reasonable workaround is not available, but does not prohibit the execution of productive work.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 Contractor will report updates and progress to the State every twenty-four (24) hours for this SLA until resolved.


(Total elapsed time it takes to repair Severity 3 Issue Service Requests)






Individual SL GYR State Mean Time to Repair (Severity 3 Issues).Green <= 5 business daysYellow > 5 business days <=7 business days

Red > 7 business days


of 118

4.4.4. Production Release Management – Successful Deployment to Production

Business Intent:

State Applications, once deployed to the Production environment perform and function within expected norms, the end user experience is consistent and responsive as demonstrated under State Acceptance testing prior to hand-off to the Contractor and scheduled jobs, processes and reports execute within the established job schedule without intruding upon online application users or other business functions

Definition: Production Release Management will be based upon the successful deployment of all LMP elements, AppExchange applications, 3rd Party extensions, code, configuration elements, RICEFW elements and other ancillary elements as required to operate the Application.The Contractor will be measured by the successful release and deployment of all elements required for Production operation and deployment of all elements in an error-free manner as to replicate those elements in their entirety as Accepted by the State without any Contractor introduced errors, omissions, gaps or inconsistencies.All the production introduction periods will utilize mutually agreeable “go-live” dates and include all elements as required to successfully operate and maintain the Application inclusive of documentation, production and performance standards and other elements included in the State’s Production Acceptance checklist that will be developed and thereafter followed by the State and Contractor. Releases shall include all scheduled Application, Patch, Upgrade, Update, and Enhancements scheduled in a month. Issues are those identified by the State, a State User or the Contractor.

Formula:System Performance and Responsiveness

=

Number of Releases with Issues Resulting in a Severity 1, 2 or 3 Production Issue arising from Contractor Efforts

Number of Releases Scheduled in a Month



Frequency of Collection: Continuous, 24 hours a day as per Production Release Schedule


Individual SL GYR State Production Release ManagementGreen < = 5%Yellow >=5% - <=7%

Red > 7%


of 118

4.4.5. Incident Resolution - Issue Triage, Closure and Recidivist Rate

Business Intent:Incidents affecting State LMP Applications, online, batch or otherwise, are promptly addressed, prioritized and resolved to the satisfaction of the State and to not reoccur or cause corollary or spurious issues to occur as a result of the repair to the element that was the root cause of the Incident.

Definition: Incident Triage, Closure and Recidivist Rate will be determined by monitoring compliance with the following four key performance indicators (KPI):

1. Incident Triage: Contractor to indicate high-level diagnosis and estimate to remedy to the State within 30 minutes of acknowledgement

2. 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

3. Incident Recidivist Rate: Closed incidents not to reappear across all in scope Services following incident closure.

4. Incident means any Severity 1 or 2 incident where the Services for which Contractor is responsible are unavailable.

Formula:Issue Triage, Closure and Recidivist Rate

=

(Total Severity 1, 2 and 3 Issues for which Contractor is responsible, where solution Services are unavailable) - (Number of Incidents where the KPI was not in compliance)

(Total Severity 1, 2 and 3 Incidents where Services for which Contractor is responsible under the Service are unavailable)

Measurement Period: Calendar Quarter

Data Source: Incident Management System Report

Frequency of Collection: Calendar Quarter, All Severity 1, 2 and 3 Incidents


Individual SL GYR StateIncident Resolution - Incident Triage and

Closure and Recidivist RateGreen >= 99.5Yellow < 99.5 and > =99.3

Red < 99.3


of 118

4.4.6. Job Schedule and Scheduled Reporting Performance

Business Intent:Scheduled Jobs and Reports Start and Complete with established time parameters and execute in such a manner as to not intrude upon online users of LMP Applications. Job abends and restarts are monitored and executed within the established schedule.

Definition: Job Schedule and Scheduled Reporting Performance shall consider all scheduled daily, weekly, monthly and business cycle Jobs and Reports that execute under the responsibility and scope of the Contractor via scheduled LMP jobs, automated operating system job schedulers (e.g., cron, task scheduler), State ETL data extractions, interfaces and any interfaces and reports in the Contractor’s scope.The Contractor shall, as part of establishing and maintaining a LMP Run Book (per State Application), establish automated schedules for LMP scheduled processes and reports and set Start, Stop and Completion and Job dependencies as appropriate.The actual Start and Completion of all Scheduled Jobs and Reports shall be recorded on a daily basis as afforded by the automated schedule. For those jobs that cannot be automated for any reason and require Contractor personnel to manually execute these jobs, the actual Start and Stop times shall be recorded and included in the below calculation.

Formula:

Job Schedule and Scheduled Reporting Performance

=

(Total Number of Minutes Jobs/Reports were delayed from Starting) + (Total Number of Minutes Jobs/Reports Ran in Excess of Completion/Stop Parameters)

Total Number of Minutes Jobs/Reports Ran as Scheduled

Measurement Period: Monthly

Data Sources: Scheduled Job Report

Frequency of Collection: Daily


Individual SL GYR StateJob Schedule and Scheduled

Reporting PerformanceGreen <= 10%Yellow > 10% <= 15%

Red > 15%


of 118

4.4.7. Service Quality – System Changes

Business Intent:System Changes are implemented correctly the first time, and do not cause unintended consequences to LMP Application users, scheduled jobs and reports, corrupt or compromise data or data relationships and otherwise perform as intended from a functional, technical and performance perspective. Non-Production environments reflect Production.

Definition: The Service Quality System Changes measure is determined by monitoring compliance with the following four key performance indicators (KPI):

1. System changes or updates (i.e., break fix, configuration, and patches) in any release to production environment are implemented correctly the first time inclusive of all code, non-code, configuration, interface, scheduled job or report, database element or other change to the production environment

2. System changes or updates are propagated within 5 business days as mutually deemed appropriate to non-production environments such that environment configurations are synchronized and reflect the then current environment and a common development, testing, QA, demonstration and training environment is carried forward that is reflective of production

3. Production system changes (i.e., break fix, configuration, and patches) in releases that do not cause other problems

4. System changes or updates (i.e., break fix, configuration, and patches) in emergency releases are implemented correctly the first time that comprise the State’s LMP platform

Formula: Service Quality – System Changes =

Total Number of KPIs not met

Total Number of KPIs met


Data Sources: Production Change Report

Frequency of Collection: Each Change to Production and Follow-On Changes to Non-Production


Individual SL GYR State Service Quality – System ChangesGreen <= 2%Yellow > 2% <= 5%

Red > 5%


of 118

4.4.8. Help Desk Services – Responsiveness and Closure Rate

Business Intent: Help Desk Services are responsive to Commerce escalated user issues and resolved correctly the first time as to provide a high quality service to LMP users that encounter non-routine system issues, errors or processing conditions

Definition: The Service Quality System Changes measure is determined by monitoring compliance with the following key performance indicators (KPI):

1. Escalated Issues are acknowledged via calls or emails are answered and acknowledged within five (5) minutes of request in the form of the original request (i.e., phone call or email).

2. An estimated time to repair or resolve the issue is provided to the Commerce requestor within fifteen (15) minutes of request and should additional time be required to resolve the issue (beyond the original estimate) be provided to the Commerce requestor prior to the conclusion of the initial estimate.

3. Routine issues (i.e., those that do not require coding, configuration or system changes) are resolved within one (1) hour of the request, and those issues that are identified as non-routine are resolved 95% of the time within the originally provided estimate.

Formula: Service Quality – System Changes =

Total Number of KPIs not met

Total Number of KPIs met


Data Sources: Help Desk Escalation Report

Frequency of Collection: Monthly


Individual SL GYR StateHelp Desk Services

Responsiveness and Closure RateGreen <= 2%Yellow > 2% <= 5%

Red > 5%


of 118

5. State Option: Field Service Technician & Technical Support Services

5.1. Remedial Maintenance and Installation Responsibilities

At the time of installation, all State deployed equipment to Liquor Warehouses and Agencies (generally PC/Laptops, administrative printers, product scanning guns, point of sale/payment devices and wireless access points) are new manufactured, in good working order and installed with the latest operating systems, device drivers and State configuration values.

The State seeks an option for offeror proposal, and should the State elect to pursue such option with the Contractor, for the Contractor to have the responsibility to make all necessary adjustments, repairs, and replacements as a recurring service, to maintain each system and related components in good working order for the term of the Contract.

The Contractor will be responsible for providing two (2) field service technicians to be available to the Warehouse and Liquor Agency operators (collectively “Field Stakeholders”) statewide to be responsible for the following Field Services.

5.2. Service Request and Response Requirements

Upon a problem or incident being logged from a Field Stakeholder, the Contractor must provide an incident report, via the web-based tracking system, to Commerce upon initiation of a service call detailing what actions were taken prior to the dispatch of a technician (e.g., remote assistance, repair, resolution), technician dispatch and repair activities (i.e., onsite assistance) and the status and closure of the problem.

Remedial Maintenance and Installation and Closure Response Requirements

The State has the following requirements for response times for remedial, and emergency maintenance and help desk calls. The Contractor must react immediately to restore services to sites that are not functioning. Once a service call is placed to the Contractor by Commerce, the Contractor must:

1. Respond back within 15 minutes to the malfunctioning site via return call response.

2. Take all necessary corrective actions to restore services and bring the system to an operational state within 3 business hours.

3. Perform hardware, software, wireless access or driver maintenance to restore services and bring the Field Stakeholder to an operational state must be completed by the Contractor and the Contractor must coordinate with the State to manage the replacement, repair or release of hardware, software, wireless access or driver maintenance products fixes, if required.

All hardware items associated with the successful and reliable operation of the system are required to be repaired or replaced with State provided spare equipment by the Contractor in order to restore services and bring the system to an operational state.


of 118

5.3. Preventative Maintenance Requirements

The Contractor must provide the necessary preventive maintenance, required testing and inspection, configuration, patch and update installation, and other work necessary to maintain State equipment in good working order and complete operational condition for the duration of the Contract and the subsequent transition period.

Preventive maintenance work must be scheduled to minimize impact to normal business operations at each location. Preventive maintenance must be performed at a time mutually agreed to by the State and the Contractor.

The preventative maintenance must minimally occur once per year and in accordance with OEM maintenance specifications. At this time, the Contractor’s personnel must provide preventative maintenance on all State supplied Field Stakeholder equipment and a quality control check on consumables in inventory.

The Contractor must perform a quality control check on each shipment, prior to leaving to perform the service call, to verify the consumables shipped are the correct items and not defective.

The State has the following requirements for preventative maintenance:

The Contractor will arrive within 30-minutes to all scheduled service visits during published Field Stakeholder operational hours. The Contractor Help Desk or the dispatched field technician must notify the Field Stakeholder of the estimated time of arrival for Contractor field technicians.

Contractor must provide on-site maintenance for the image workstations such that no liquor enterprise location is without an all-purpose workstation capability for more than two (2) hours for 99.5% of the calls requiring service to equipment that cannot be done remotely (i.e., require a visit). Contractor must repair or replace defective equipment at the Field Stakeholder location of the equipment within the specified, required time frame.

The Contractor must be fully responsible for reliability, performance, and efficiency of State provided equipment and must provide reliability data to the State where available from the equipment manufacturer (initially) and then based on State actual use, quarterly updates thereafter.

The Contractor must perform preventive maintenance according to manufacturer’s recommendations during remedial maintenance visits – or at least once yearly in instances where no remedial maintenance visit was recorded for that particular site.

The Contractor must establish a routine service and maintenance schedule in conjunction with the State and agrees to coordinate maintenance visits with Field Stakeholders as to adhere to required service/maintenance intervals and not disrupt routine Field Stakeholder operations serving the public. Further, Contractor field service technicians and Help Desk representatives must co-ordinate visit schedules in a manner acceptable to the Department of Commerce. Call information must always be made available to the Department of Commerce using a web-accessible system.

All maintenance activity performed at sites must be closed out/approved with the Department of Commerce supervisor. The name of supervisor and date/time of repair must be recorded by the Contractor, along with any comments provided by the field service technician or the Department of Commerce supervisor. This data must be attached to the call/ticket incident report and becomes a part of the record for that call.


of 118

5.4. Maintenance Reporting Requirements and Responsibilities

The State will provide an adequate supply of spare parts (whole unit spares and individual spare parts as recommended by the equipment manufacturer) as well as what is required by Field Stakeholders as “State spares”.

All service request / resolution data is maintained within by the Contractor and made available via web access to the State. During the implementation phase, the Contractor must establish mutually agreeable reports that must be generated per the Department of Commerce requirements.

At a minimum, these reports must be as follows:

Daily Reports

1. An “open request status report” showing all open service requests with all performance and response time information.

2. “Requests closed since the last report” listing all closed resolved requests with pertinent problem, resolution, root cause, and performance information.

Should the State identify a systemic or repeating issue affecting a large number of site(s) or device(s), the State may require that these reports are discussed via daily conference call between the Department of Commerce and the Contractor until the Department of Commerce is comfortable that all service requirements are being met.

Monthly Reports

1. Volume Summary - Each month a summary of all service requests must be provided by the Contractor that quantifies problem types, resolution types, etc. by equipment type. This information must include a previous twelve months to help identify trends as well as “remote” and “in-person” resolutions to problems.

2. Inventory Report - Each month a comprehensive inventory is reported that shows the location and status of all State equipment. This report must track all installed equipment, spare pool hardware, and equipment out for repair. Any equipment that is permanently removed from service will be considered “retired” and can no longer be transacted against, but a record should be maintained in an inactive status for historical purposes.

3. Performance Report – This monthly report must list all of the performance data against State requirements including; response time, ETA, arrival time, time to repair and close time against Field Stakeholder business hours. This data is generated monthly and published with a twelve-month history for trend analysis.

4. Ad Hoc Reports - Contractor must provide reports to the State on request that will in general be specific to State needs regarding: problems, call volume analysis and comparison at the site level, site history reporting, operator history reporting etc.

Should the State determine that there appears to be an issue with a hardware device statewide, the Contractor must review data with the State and the equipment manufacturer to determine if corrective action is necessary. If


of 118

there appears to be an issue at a few Field Stakeholder sites only, the Contractor and the State will investigate the data to determine if additional training is necessary for staff at these locations.

After Contract award, Contractor must determine what catastrophic failure plans are already in place at Field Stakeholder sites and must provide appropriate measures to the State that will be in line with the overall system catastrophic failure system wide plans.

5.5. Preventive Maintenance and Support Plan

The offeror must submit a detailed preventive maintenance plan describing all preventative maintenance tasks, schedule, frequency of each task, time required to perform each task, and staff responsible for performing each task, etc. for all provided solution elements.

Contractor must follow the recommended preventive maintenance practices as provided by each original equipment manufacturer. Cleaning activities must be carried out by Contractor field service technicians to ensure optimal equipment performance.

The Contractor’s operations manager must consult with Commerce prior to scheduling the maintenance visits and maintenance related activities and follow the State requirements for proposing the schedule of the maintenance activities.

Maintenance hours will generally range from 9:00 am to 9:00 pm, Monday through Saturdays excluding State holidays.

In case of emergency, with prior approval from Commerce, the Contractor Operations Manager must schedule the disaster recovery operations as required regardless of the hour.

5.6. Telephone Support and Notification Requirements

The Contractor must provide a toll free dedicated support line where the State Liquor Help Desk can call to order consumables, request support, and address remedial/maintenance activity on behalf of the State Liquor enterprise.

This line must be effectively available from 7:00 am to 9:00 pm Monday through Saturday, excepting State holidays.

The Contractor’s Help Desk Operator must receive calls and update a call tracking system with a service request. The service request must be able to be monitored by Commerce personnel via the web-based tracking system.

The Contractor must provide a Single Point of Notification for their call center and document procedures for reporting, tracking, and obtaining status on problems. Furthermore, the Contractor must provide documented procedures for dispatching service staff, coordinating, resolving, and following-up with Field Stakeholders on calls.

The Contractor must verify the closure of calls on a daily basis with Commerce. Contractor Customer Service Representatives interact with the Contractor field services personnel to schedule visits and own responsibility for informing and co-coordinating these visits with Field Stakeholders users/supervisors accordingly.

The Contractor provided web-based help desk system must ensure prompt reporting/tracking of issues and statuses that must be readily available to Commerce. In addition, Contractor’s Help Desk Supervisor must use the


of 118

process of daily status calls to follow-up on open calls and provide estimated time of fixes within the established SLA’s.

The Contractor must provide a fully configured and functional Web Tracking and Reporting system that must, at a minimum, provide the following functions and requirements:

1. Incident recording or incident call tracking.

2. It must be possible to create, track, and update trouble calls.

3. Management of work orders through web-based calling system.

4. Users must be able to generate reports for tracking of timelines, system related failures and other related issues.

5. System must be available from 7:00 am to 9:00 pm during scheduled business days, excluding State holidays.

6. Web-based incident reporting capabilities as well as by phone and e-mail

7. Owned, operated and maintained by Contractor.

8. Toll free telephone support.

The Contractor’s Help Desk must review and acknowledge receipt of all tickets within 15-minutes. The resolutions must be recorded and reconciled within the web-based help desk system for the consumption of fellow Help Desk Operators and facilitating the generation of reports.

The Contractor must provide an incident report via the web-based tracking system to Commerce upon completion of a service call detailing the actions taken to resolve the problem and status of the problem.

5.7. Solution Element Change Management (Hardware, Software, Devices and Other Offeror Provided Elements)

The Contractor must ensure that all changes to the State field operating environment during the lifecycle of the contract, no elements are added, modified, replaced or removed without appropriate authority and traceability and that Change Remedial/Maintenance control is exercised at various levels within the State.

The Change Control Process must define the procedures that will be followed for managing changes in the scope, schedule, resources, or costs of the service to the State and include processes for initiating, analyzing, approving and tracking change requests.

The Change Control Process must involve the State Project Manager and Contractor Project Manager, each of whom must seek input from their relevant State stakeholders. The Contractor, via the Change Control Process, must perform State approved changes following State’s approval to do so.

The Contractor must establish and follow a release management process for all release updates or changes to the State and the Contractor is responsible for ensuring that only authorized new or modified system components are rolled out in the Production environment in a way that must ensure minimal disruption of activities that may impact the State. A release can consist of hardware, software, device drivers and interface software.


of 118

All releases must be tested by the Contractor prior to being deployed at any State environment. The Contractor must ensure that:

The release contains only changes/new features, authorized/approved by the Change Control process.

The traceability of the changes / new features is maintained and documented, i.e. it can be linked to the requirement / change request.

All project artifacts impacted by the change are either included in the release or are scheduled for a later release. This includes any documentation associated with a system feature change must be reviewed to ensure that the change is adequately reflected in the documentation.

The Contractor must document and follow the process for release / patch deployment to Production environments and equipment. The process must ensure that product updates and upgrades are transitioned to Production seamlessly without causing any disruption to the State. This includes releases for customer or State facing systems, test or demonstration systems, databases, or card production systems.

The releases must include any of the following, at a minimum:

Product updates, fixes or patches to include enhancements / modifications as per change requests or according to the Contractor product enhancement strategy.

Bug fixes to resolve production issues – Bug fixes may be required to be moved as emergency hot patches or fixes.

Operating system / licensed software updates / upgrades / security patches and updates to the Contractor provided software, device drivers and other Contracted provided elements to comply with State security and operating system deployments.


of 118

6. Project Based Services

6.1. Project/Enhancement/Upgrade Delivery: Full Lifecycle SDLC Deliverables and Process

Contractor must provide a disciplined systems development life cycle methodology for use on application development and maintenance projects and must adhere to such methodology during the performance of Application development Projects. Contractor must adapt this methodology as required to meet the State’s needs. Contractor must 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.

The Contractor shall establish and follow a change approval methodology as follows based on the size of changes to the environment:

Small Changes – changes that are either within the budgeted Legal/Regulatory and Minor Change hours pool or are less than 500 hours of Contractor effort to plan, manage, design, build, test/validate and move to the production environment. Approval: State Service Assurance Lead

Medium Changes – changes that are less than 2,000 hours of Contractor effort to plan, manage, design, build, test/validate and move to production or beyond the available budgeted discretionary hour pool: Approval: State Account Representative

Large Changes – any project or single change greater than 2,000 hours or otherwise not addressed in prior categories. Approvals: Commerce CIO, State CIO

The State maintains a project management and systems development methodology (generally based on CoBIT, ITIL v3 and CMM) that is used at varying levels for complex, transformational Information Technology projects. This methodology is designed to provide a substantive and objective framework for the reporting and review of projects to impacted stakeholders and, should the need arise identify the need for corrective action for one or many of the participants in a project (e.g., State, Contractor, Customer, Stakeholder).

The State acknowledges that various contractors that may do business with the State may maintain unique or proprietary project management methodologies, but seeks to ensure that projects are delivered to the State as contracted. Therefore, a minimum project management reporting standard has been created to serve the State’s project management and oversight needs while not adversely impacting or influencing Contractor provided delivery methodologies.

The Contractor must provide a project plan and execute the project as agreed with the State. For purposes of a medium or small project plan specific phase and gate dates, effort and costs are a sufficient minimum.

For any large effort as described above, the Contractor must include the following deliverables and milestones within their detailed project plans and methodologies and at a minimum, upon commencement of the project:


of 118

State Development Methodology, Minimum Activities, Work Products, Deliverables and Milestones

1. Project Set-Up 2. Requirements Confirmation and Project Management 3. Design Phase Elements (System and Process)

Establish Steering Committee/Oversight Create Summary Plan Establish Key Milestones Establish Key Deliverables Establish High Level Project Plan Create Cost/Time Analysis (Budget) Establish High Level Dependencies Create High Level Project Schedule Establish Scope/Statement of Work & Methodology

Create/Maintain Refined Project Plan Establish Implementation Strategy Assess Internal/External Project Dependencies Assess Internal/External Risks Create Detailed Project Plan Create Stakeholder/Customer Communications Plan Create Detailed Resource Plan Establish Level 0 System Design Model End-User Characteristics Determine Existing Process Change Model Identify New/Enhanced Business Processes Finalize Implementation Strategy Analyze Impact to Enterprise Architecture/Data Model Develop Deployment Strategy Finalize Development Tools and Production

Requirements Validate Customer Adoption Assumptions Establish SDLC Environments

Follow/Track Final Project Plan Establish Final Cost & Time Estimate Outline Phase/Release Schedule Create Detailed Design Documents - Functional Create Detailed Design Documents - Technical Establish Performance Requirements Establish Support Requirements Establish Operating Requirements Obtain System Application Software, Tools Create Process Flows with Key Inputs/Outputs Create Interface Control Documents Create Conversion/Migration Plan Create Integration Plan Develop Stakeholder Communications Materials Establish Technical Requirements Create Solution System Architecture Documents Update Enterprise Architecture Documents Create System(s) Sizing Requirements Establish Test Plan Brief/Update User Stakeholders/Customers

4. Development Phase Elements(Systems and Process) 5. System, Process & Acceptance Testing 6. Production and Operational Readiness

Follow/Track Final Project Plan Establish Final Cost & Time Estimate Outline Next Phase Schedule Create Detailed Design Documents - Process Create Detailed Design Documents - Functional Create Detailed Design Documents - Technical Establish Performance Requirements Establish Operating Requirements Finalize Process Flows with Key Inputs/Outputs Finalize Interface Control Documents Finalize Conversion/Migration Plan Create Integration Plan Develop Stakeholder Communications Materials Create Solution System Architecture Documents Update Enterprise Architecture Documents Create System(s) Sizing Requirements Establish Test Plans (Unit, System, Acceptance) Change Management Stakeholders/Users (Prep) Establish System Test Expected Results Establish UAT Expected Results Establish Test Plan & Procedures

Develop/Execute Overall Test Plan Establish Final Processes Establish Q/A Metrics Develop UAT Plan, Scripts and Cases Complete Final Sizing Analysis Establish Operational Performance Baseline Publish Committed Capacity Plan Prepare Component Test Analysis Report Develop Training Materials Execute Component Test Collect Performance Metrics Create Component Technical Documentation Perform User Acceptance Test Document/Prioritize/Publish Issue/Bug List Remediate Launch Critical Issues/Bugs Create Remediation Effort/Schedule for Outstanding

Defects Perform Final Performance Testing Collect Performance Metrics Produce System Test Report Create System Operational Documentation

Perform User Training/Change Management Document/Publish Final Policies & Procedures Publish Final Procedures Create System Technical Documentation Publish Version / Release Document Develop Training Scripts Develop Training Guide Create Operational Documents Create User Job Aids Update User Stakeholders / Communications Update Job Schedules and Dependencies

7. Production Deployment / Closeout Compile Release Checklist Update Business Contingency / Continuity Plan Transition Operational Procedures Publish Job/Control Schedule Establish SLA Parameters Assemble Audit Impacts (integrity, security, privacy) Create Release Verification Checklist Execute Operations Training Perform Release Verification Update Enterprise Architecture and Data Model Update Data Center Environments Perform User Training Disseminate Documentation and Procedures Remediate Go-Live Issues Perform Post-Production Support Period (P1, P2) Seek/Provide Final Acceptance

Release upgrades for packaged software are initiated through periodic releases by each software OEM, including the software licensed by the State from the Contractor and other infrastructure releases. Due to the packaged


of 118

nature of these releases, the State requires that the Contractor support and coordinate efforts to analyze, install/apply, test/verify and utilize these releases in the State’s LMP environment. As the State is responsible for infrastructure operations, this coordination and leadership must be well defined and executed so that the State can realize the benefits of the release while not introducing any infrastructure or application related issues.

Further, 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 and is committed to maintaining the State’s LMP system and related software at the most current proven release at all times in such a manner as to maintain ongoing compliance with OEM requirements for maintenance of OEM provided elements that comprise LMP.

The State considers any 7.x to 8.y upgrade a major upgrade, any 8.x to 8.y a minor upgrade and 8.x.x to 8.x.y a feature update/patch (or subsequent versions as available over the term of this Contract) as a minor upgrade for the LMP Environment.

All consulting services required to support minor or major upgrades must be scoped and planned in detail at the time the requirement arises and supported within this Work Area and are to 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.

The Contractor must comply with the following requirements as part of delivering services to the State:

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 OEM.

As part of annual planning and coincident with monthly governance review meetings, the Contractor must inform State of any software, hardware or infrastructure components that they are aware of that are moving beyond a current support model and present a plan to implement the required updates in a controlled manner to the applicable State environments to maintain compliance with software OEM support models

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

Upgrade and update efforts must factor any regularly scheduled batch processing or system availability as well as any seasonal processing requirements (e.g., end of year 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 must lead any assessments of the need for an application enhancement;

The Contractor responsible for the design, development, and implementation of the Minor/Major enhancements in the State environments in accordance with the previously presented roles/responsibilities table (this includes requirements/design discussions, applicable conference room pilots, design review/signoff, document design specification, document and execute unit and integration/interface tests, support of the State in executing UAT);


of 118

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 the State for end user change management/communication)

The Contractor must provide technical support services required for enhancement (e.g., tuning the performance of LMP and underlying database elements, integrating with State technical infrastructure).

The Contractor must verify, accept, and implement enhancements not developed by the Contractor (e.g., review designs, execute tests, migration to production).

All System Enhancements must be performed in accordance with the appropriate software development lifecycle procedures in this document.

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

Notwithstanding Major and Minor Upgrade enhancement requirements as outlined above, the Contractor has an obligation to maintain all LMP elements in keeping with a current support model, the service level requirements as outlined in this document, 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 warranty, support, performance and ongoing upgradeability of underlying software, hardware and ancillary elements of the Service.

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

Unless otherwise agreed in writing with the State, all Major Projects; Upgrades and Technical Refresh work efforts must include and follow the Software Development Phase Deliverables, Requirements and Responsibilities – inclusive of design, build, test, acceptance and deployment subsections contained in this section below.

6.1.1. Software Development Design Phase Deliverables and Responsibilities

During any software development phase, the Contractor must:

Conduct a Joint Application Design session to define and document detailed functional design for Contractor Solution Components

Define foundational capabilities and application functionalities to enable efficient processes and processing for all user groups and implement standardized application approach across State requirement areas

Validate requirements for in-scope capabilities and compliance areas and review as-is business processes as applicable to the scope

Design to-be business processes (inventory and process mappings) as applicable to the scope

Create Functional Design Document (FDD) for Application & Application Components, Integration Components, and Data Conversion & other related components as applicable to the scope


of 118

Create Technical Design Document (TDD) for Application & Application Components, Integration Components, and Data Conversion & other related components as applicable to the scope

Complete Middleware Design & Architecture as applicable to the scope

Meet requirements related to System Environments defined in this document

Deliverable 1. Phase Design Document ( Repeats for Each Release, Phase / Cycle) Inclusive of all functionality contained in the phase (business, functional, technical,

integration, operational or otherwise)

User Interface and Customer Management Requirements

Transaction Routing and Processing Requirements

State Interfaces, Integration and Reporting

6.1.2. Software Development Build Phase Deliverables and Responsibilities

During any Build Phase the Contractor must:

Build foundational and advanced solution capabilities as applicable to the phase;

Build new solution requirements as applicable to the phase;

Leverage, augment, configure or extend pre-built requirements as applicable to the phase;

Complete data conversion design and build, as applicable to the phase;

Meet requirements related to Project and Phase Completion defined in this document;

Meet requirements related to System Environments defined in this document; and

Meet requirements related to Version Control defined in this document.

For any system code, scripts, job schedules, objects, rules, metadata, database, scripts or other programming artifacts (collectively “Development Items”) that lend themselves to documentation that the Contractor develops, modifies, enhances or replaces, the Contractor must, during the project, fully document any Development Items in a manner as to comply with the following standards:

Documentation of Development Items comply with Contractor (and if applicable 3rd party software) OEM best practice guidance for adding comments to code (in general);

Documentation must be sufficient for a capable third party to assume, adjust, alter, maintain, support, update or upgrade the system in the future without the involvement of the Contractor;

Comments must additionally follow the project specific requirements below:

The Contractor must use comments to describe the intent, algorithmic overview, and logical flow.

The Contractor must include comments so that someone other than the original developer can understand the intent, behavior and purpose of the code.

The Contractor must use comments liberally for all State specific functionality on Development Items and where State specific functionality integrates with baseline system capabilities or LMP functions as implemented at the State.


of 118

The Contractor must include comments that indicate who made the changes, when the changes were made, why the changes were made and what the changes accomplish and (if appropriate) what phase, release or version number of the system the Development Item was developed for.

The Contractor must ensure that:

Complex Blocks of Code are properly commented

Comments must not be used to serve as inline translations of the code; instead they should focus on the intent and function of the code.

Comments must be used to classify the modification type.

Reasons must be given if any base layer code is commented.

Unnecessary or inaccurate comments are removed.

The Contractor must identify all methods that are missing XML header documentation that outlines the summary, parameters, return values and remarks for the method. For these items, the Contractor must add proper documentation for each method.

The Contractor must ensure that the system label dictionary contains all standard and customized labels and that all tables, extended data types and base enums contain a valid label id assigned to the label and help text properties. As part of this work the Contractor must replace all static text with valid label code for extended data types, tables, table fields, views, view fields and maps in the system model store.

The Contractor must ensure that all custom objects follow a proper naming convention and must rename custom objects in accordance with the naming conventions that other objects appear to follow and adhere to industry best practices.

Deliverable 2. Build Completion Document ( Repeats for Each Release, Phase / Cycle) Completion of the build phase and all requirements contained in a phase

Other delivery artifacts as well as documentation as required in this document

Environments Accepted- State approval that represents that all SLDC, operational and disaster recovery environments have been established as required.

Version control mechanisms are installed and functional and that all development activities that are subject to version control are managed by the environment prior to any promotion of development objects to User Acceptance and Production environments.

6.1.3. Software Development Testing Phase Requirements and Deliverables


Create Solution Testing and Acceptance Strategy as applicable to scope of the phase, release or cycle;

Update test plans, scripts, functional matrix, schedule, scenarios, and processes that must be used for the system integration test;

Build performance test plan for the scope elements;

Execute application and integration Performance Testing approach and plan;

Address any issues identified during performance test, publish performance testing results;

Complete Systems Testing integrated with the Application and other State system software components;


of 118

Support State User Acceptance testing plan based on in-scope business processes and business scenarios (as defined in Business Requirements Document(s) and the Functional Design Document(s)) that must be used for User Acceptance Testing;

Identify build, test and deploy defect fixes identified during all testing which includes Contractor and State testing and deploy code fixes to all relevant environments; and

Meet requirements related to Test Phase Exit, Production Deployment, and Production Transfer as required in this document.

A Test Readiness Review Checkpoint must be successfully completed prior to beginning the Test phase. This includes the State’s acceptance of all deliverables due to date per the project schedule. A validation of the scope and schedule for the remainder of the Project must also be completed at the Test Readiness Review Checkpoint.

For avoidance of doubt with respect to testing activities, the Contractor is responsible for all activities associated with System Test. The State is responsible for UAT Test execution while Contractor must be responsible for UAT support, which includes at a minimum, test preparation, management and tracking of UAT activities. The Contractor Team must plan, lead and execute System Test, User Acceptance Test (“UAT”) Support, and Operational Readiness Test (“ORT”) and include the State Project Team and Participating State Team(s) in the effort. The State will provide SMEs knowledgeable in test execution and as mutually agreed to with the Contractor to support test execution.

Following are the testing focus areas and the State’s expectation for each of the test cycles:

System Test focuses on the customizations, configurations, workflow and integrations. Test conditions and test scenarios to be included in the System Test must be mutually agreed upon by the Contractor and the State. These scenarios will be based on an analysis of the requirements, changes, and modifications that are approved for implementation. System Test includes integration and regression testing.

Performance Test establishes a baseline of acceptable performance for a sample of online transactions. The tests are conducted under a practical proportion of expected transaction and user volumes to mimic real-world usability. The number, frequency, and concurrency of online user transaction load must be defined using the most recent Contractor team estimates of activity available at the time of test preparation. The estimates must be based on enterprise-wide usage.

User Acceptance Test (UAT) verifies the usability of the new processes and ensures that the system meets the needs of the organization and the end user. UAT leverages System Test Scripts and is executed by State resources. A key objective of UAT is to facilitate an understanding of the technology and the business change being implemented.

Operational Readiness Test (ORT) must include end-to-end testing of business processes, all delivered system functions, interfaces and reports and the underlying technologies that support the solution and must be planned, led and executed by the Contractor and include the Contractor Personnel responsible for the design, construction and system testing of the system, State Project team and Participating State Team(s) in the effort. ORT must be conducted during a specific time period before Go-Live as a final business readiness test prior to live commercial use of the system.

Security and Vulnerability Test must allow the State to conduct a test with the support of the Contractor that includes an application scan, manual testing of the system using client-side code analysis, and loading maliciously formatted inbound interface files.


of 118

The Contractor Team must develop and prepare weekly status reports to monitor the progress of each test phase. The status reports must contain sections for condition creation, script creation, script execution, issue identification and resolution, and defect identification and resolution

The Contractor must provide and follow a Test Moves to Production strategy and plan as appropriate for their solution’s environment(s). The Contractor must demonstrate to the State that the strategy allows for the development and testing of a migration process and checklist, as well as an assessment of timing and any mitigation or resolution of any issues related to timing.

Throughout the Project duration, if a testing or production incident is due to errors, omissions, documentation inconsistencies, or defects in a software element licensed by the Contractor or a Third Party to the State, the Contractor must assist the State by referring such incident to the appropriate entity for resolution and coordinating with the Contractor, as appropriate, to help minimize the State role in problem management.

The Contractor must implement measures to help avoid unnecessary recurrence of incidents, by performing root cause analysis and event correlation for items discovered during testing/validation activities.

Deliverable 3. Contractor System Test Phase Completion ( Repeats for Each Release, Phase / Cycle) State acceptance of completion of the System test phase and all Contractor requirements

and delivery artifacts as well as documentation as required in this document.

Deliverable 4. State Acceptance Test Phase Completion ( Repeats for Each Release, Phase / Cycle) State acceptance of completion of the Acceptance test phase and all Contractor

requirements and delivery artifacts

Testing must be sufficient to validate the overall completeness, accuracy and quality of the solution inclusive of all system development activities and as applicable to live production use within the State.

Deliverable 5. Disaster Recovery/Data Backup (DR, DBK) Completion of DR testing sufficient to ensure that the system contains features and

capabilities as required to meet the State’s disaster recovery requirements, at a minimum as to replicate all technical elements of the system inclusive of code, data and configuration values to an alternate location as to resume operations in the event of an unanticipated disaster.

6.1.4. Software Development: Retirement of Legacy Functionality and Data Migration, Decommissioning

As part of transition / migration / decommissioning of any legacy State business functions and data associated with a deployment of a Project to LMP, the Contractor must design and execute a comprehensive transition and migration plan for each release phase of any proposed solution.

These requirements must be delivered with a seamless migration of business transactions and the conversion of data and business functions from the State solution as to create a consistent and coherent user experience for users that may be transacting business utilizing LMP functionality until such time as the State application is fully replaced. The Contractor must ensure that reconciliation reports and controls are in place to validate no data, transactions or revenue is lost in transition or migration.

The Contractor must ensure that:


of 118

Users must have access to complete historical, current and in-progress data in single operating environment;

Reconciliation processes and reports must be in place to ensure the new system is processing the same volume and revenue of transactional data as the legacy application and no data is lost in transition; and

The new system or system elements are covered under a proven and tested Disaster recovery and Data Backup/Recovery as part of a State business continuity plan.

As part of migrating functionality or data from a State system to LMP, for each functionality area or data group that is intended for live production, the Contractor must:

Identify, with State assistance, all data records in the list of conversions detailed in this document subsequent to this identification. The Contractor must develop data extraction and data conversion reports to validate, extract, transform (if required) and load the records identified into the LMP;

The State is responsible for any data extraction from legacy State systems and loading it into staging tables.

The State will either remediate these records or determine alternate methods to process (or if necessary exclude) records that require remediation.

Work with the State to ensure that, prior to any decommissioning of functionality or data from the legacy environment (once the data and business functions are in production in the LMP environment), the State has successfully archived the then current legacy system and data in a retrievable fashion;

Develop, test and maintain a reversibility plan such that should (for any reason) the State elects to revert back to legacy functions migrated in a release cycle in a period immediately following go-live, it can do so through re-application of legacy functions and data;

Perform a data assessment and identify any records that require State remediation prior to loading in the LMP environment;

Following State remediation (if appropriate) and for those records that do not require State remediation, load all records into LMP and provide control reporting sufficient that all records were loaded, fields mapped, no data was altered or lost, and the records are as a group and uniquely accessible in the new system;

Design, build and migration and decommissioning test reports, while ensuring all the necessary security and privacy controls are in place;

Work with the State, agencies and external system (e.g. Reporting, Banking/Payment Processing/ESB integration) teams, to identify the scope, required data elements, frequency, security and controls of reconciliation reports;

Work with agencies and external system teams, to design, build and test reconciliation reports; and

Contractor must design, build, end-to-end test and deploy LMP and middleware integrations up until the State hand-off.

Deliverable 6. Legacy Function and Data Decommissioning Report ( Repeats for Each Release, Phase / Cycle)

Plan to decommission application functionality and compliance areas

Decommission and shut down of legacy system service areas as LMP-based functions, data and service areas come online, as applicable to the release, phase / cycle;


of 118

Decommission of redundant functionality in instances where capabilities must be enabled on LMP (e.g., logon, account management and user registration)

Deployment plan to migrate system changes to Production as required, given other decommissioned functionality

6.1.5. System and Acceptance Testing Requirements

For any LMP technical implementation, all software and code-based deliverables, development, upgrade / update 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 must be developed for each build as soon as possible after establishing the business and user requirements. The testing and acceptance process must include sufficient audit trails and documentation as required to track and correct issues. The tasks and activities that the Contractor must perform as part of the testing and acceptance process include 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:

System Test / Assembly; Integration/interface testing and regression testing for new releases of existing applications; and 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 populated with quasi production data as required to perform the system and user acceptance testing work, and where appropriate performance testing. The test environments must be designed and maintained by Contractor so that test activities will not adversely affect the production environment.

Ensure that all developed software is not constrained by, and executes within agreed performance parameters on the LMP platform or State provided infrastructure; and

Perform technical architecture build/configuration testing (e.g. batch scheduling, interfaces, operations architecture, etc.).

Deliverable 7. System and Performance Test Results All Functionality Contracted by the State in each Phase/Release/Cycle/Sprint as

applicable

All RICEFW elements Contracted by the State in each Phase/Release/Cycle/Sprint as applicable

Documented system and performance test results for State review and acceptance prior to the State’s commencement of acceptance testing.


of 118

6.1.6. Performance and Reliability Testing Requirements

For any effort that involves the development of software code, custom configuration, scripts, batch processes, interfaces, data extractions, extensions to LMP, changes/alterations (collectively Contractor Developed Elements) to LMP and data structures and the like, the Contractor must work with the State to develop an overall approach to performance testing of the impacted State and LMP elements as a result of the work described in this document.

The Contractor must specify the appropriate performance testing approach that includes the design and execution of processes designed to demonstrate to the State that performance for any Contractor Developed Elements adheres to the agreed upon performance parameters and does not diminish the performance of LMP and State Applications beyond agreed values as a result of introducing the Contractor Developed Element into a State environment.

The Contractor must specify test environments as required to perform the appropriate performance testing. The test environments must be designed, implemented and maintained by Contractor so that test activities must not adversely affect any production environment.

Contractor must expand capacity if testing requirements are constrained by the hardware or environments.

The Contractor must provide best practices in conjunction with the overall performance testing effort. To facilitate rapid and quality testing, with a high degree of code coverage, the Contractor must employ automated testing tools and techniques where possible to test scenarios, scenario variations, and regression testing of performance testing items.

6.1.7. Support the State’s Performance of User Acceptance Test (UAT)

The Contractor must support the State’s user acceptance testing for solution components as follows:

Develop with the State agreed upon UAT test plans, scripts, cases and applicable acceptance criteria.

Coordinate UAT execution and acceptance procedures with the appropriate the State participants.

Record and report UAT results.

Review changes, fixes and enhancements with the participants in the UAT testing.

Correct identified defects and nonconformities in accordance with the acceptance process.


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.

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

Provide the State with a database extract from the database that tracks progress of Contractor’s performance of testing work, all documented defects, defect prioritization and defect find/fix/retest activities (particularly those required for launch as well as all Severity 1 and 2 Defects).


of 118

Deliverable 8. State User Acceptance Testing Completion

6.1.8. Pre-Production / Production Deployment Phase

The Contractor is responsible for working with the State and its 3 rd party contractors, and executing the production deployment and roll-out of any LMP Implementation to the Production Environment provided by the State.

Should the deployment include any software deployment to the end-user desktop equipment, State infrastructure inclusive of file servers, networks, database servers or related elements (if applicable), identification of interfaces and any required conversions/migrations, installation and testing of any required middleware products, installation of server software, the Contractor must perform all required testing to achieve the proper roll-out of the Application software to any system environment.

Contractor must 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 is responsible for business user support required during the initial weeks of a production deployment as determined by the affected State business units and must maintain the capability to provide enhanced levels of support during the term of the Contract. Contractor must 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 Infrastructure Services Division, if applicable. The tasks and activities to be performed by Contractor as part of the Deployment Services also include the following:

Execute required data conversions or migrations including, but not limited to, baseline LMP configuration tables and parameters, and ancillary supporting data as required by the system to function successfully in the production environment;

Establish data to be used with the new solution by producing new data and reconciling and mapping different data and database representations.

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

Perform required data matching activities and error reporting.

Document data issues and provide to the State for resolution.

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;


Perform end to end final validation of the operational architecture for the system;

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.

Deliverable 9. Final State Acceptance and Handoff to State Operations Completion of all items documented in the State’s Production Acceptance Checklist

Resolution of all Severity 1 and 2 Defects and other defects as mutually agreed with the State

Transition solution support responsibility to the State Operations as appropriate.


of 118

Conduct a post-implementation review process upon the completion of the Project which must 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.

6.2. Knowledge Transfer and Educational Services

The Contractor must design and provide the State a formal knowledge transfer and education service in connection any major release of the Dynamics A/X software six months preceding the expiration or termination of the Contract arising from this document.

6.2.1. Periodic/Ongoing Knowledge Transfer and Training

In addition, on a continuous basis, the Contractor must conduct informal information sharing and knowledge transfer services coincident with the “go-live” of any mutually defined release of State developed functionality in such a manner as to ensure that State personnel assigned to support, develop, manage or operate the LMP platform are apprised of the contents of each release, features, functions, known defects and workarounds and other information as to manage and communicate to State leadership (in general) and business stakeholders of the system and State functional leaders (specifically) as to the most effective use of the then current system assets (i.e., the LMP platform and State developed enhancements or extensions).

6.2.2. State IT Change Management/Communications and Update Briefings

Coincident with any State Application production implementation, the Contractor has the following responsibilities with regard to the effort which are additive to the general responsibilities contained in this document as they pertain to Change Management and Communications of the State IT Team and State Leadership teams that utilized the LMP platform. Each will be discussed in turn:

Change Management/Communications

Contractor must work with the State to develop general communications materials regarding the scope, anticipated impact of change with regard to the contents and impacts of any release to the LMP platform. These communications documents must be focused (at a minimum) on general communique to service delivery staff and State expert LMP users (generally less than 10) for onward dissemination to State development and service delivery teams and customers by the State;

For expert LMP State Users, the Contractor must develop progress and design summaries to be shared by the State with these users; and

For the IT service owners that support State customers and State help desks, the Contractor must develop targeted presentations that highlight specific system support processes, workflows, job aids and updates arising from the solution implementation.

Service Delivery Functions Update Briefings

For State Expert Users, the Contractor must develop for the State to publish general guides containing FAQ, one-page “how to” and help pages for State on utilizing the new system for required Applications; and

For the State Service delivery functions and Business support functions within State the Contractor must develop targeted information sharing sessions as appropriate to Business, Operations (e.g., State IT


of 118

personnel) and Technical (e.g., State developers or infrastructure personnel) to be delivered that highlight the implementation, use, changes, workflow, reporting and other use considerations in such a manner as to facilitate business and technical support functions.

Targeted Knowledge Transfer Sessions (IT Team)

The Contractor, in consultation with the State, at a mutually agreeable time (generally coincident with major system releases or upgrades) shall design and deliver targeted knowledge transfer sessions to be delivered to State system administrators and IT personnel sufficient for the State workers to perform the following tasks: Simple Configuration Updates; Moderate Configuration Updates; Systems Administration activities; and Batch Processing.

6.3. Contractor System Development Environment Management Responsibilities

Based on the modules implemented to date, a high-level context is as follows, please note that the State Liquor system, supporting applications, integrations and reporting systems run in unique “Business Environments” due to the fact that configurations, customizations, operational considerations represent different stages of ongoing system development, testing and deployment activities.

Offerors are encouraged to consider the merits of these “business environments” under the tenets of this Supplement and propose (if feasible and advisable) moving these environments to a more common set of operating standards to drive efficiency, cost, State licenses and other consolidation/optimizations. Should the State agree with such approaches, the offeror, as Contractor must perform the consolidation/optimizations as contracted.

6.3.1. Environment Management Requirements

As part of the end-to-end Managed Service, the Contractor must include the ongoing management and maintenance, encompassing deployment/management, testing and training environments for the instances of the State’s applications and supporting extensions 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 based upon Microsoft best-practices, the offeror may do so in their response to this section.

State Liquor Management Systems Environments and General Sizing

Environment (refresh requirements) Data Volume / Scope User Count Estimate

Demo / Sandbox (quarterly) Sample Test Data 10-20

Patch, Testing/Staging (quarterly) Sample Test Data 5-10

Development (monthly) Sample Test Data 10-20

Configuration (monthly) Full Production Data, 3 most recent months 5-10

Quality Assurance/ Testing (quarterly) Full Production Data, 3 most recent months 5-10

Acceptance Testing (quarterly) Full Production Data, 3 most recent months 10-15

Production (scheduled releases) Full Production Volume 5,000

Disaster Recovery (State Provided Location) Full Production Volume 5,000

Training Delivery (scheduled releases) Sample Test Data 30-50

Proof of Concept (quarterly) Sample Test Data 5-10


of 118

High level descriptions of the instances are as follows:

Demo: This is the instance delivered by Microsoft 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 Microsoft 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 State LMP environment. Configuration changes for the other applications are made in other environments.

Quality Assurance / Testing: 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.

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

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

Disaster Recovery: A replica of Production to be managed (as an environment) by the Contractor for State DR.

Training Delivery: This instance is used for classroom and web-based training.

Proof of Concept: This instance is used for exploratory development and product testing and to assess AX and LMP developments and releases in conjunction with a major releases and new Application implementation planning.

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

The Contractor must support the provisioning of the LMP environments utilizing State provided licenses and replication of production data or production data subsets using applicable data masking procedures, this may include design, development, testing, pre-production implementation and migration staging, production or disaster recovery validation, additional processing requirements for peak or seasonal requirements or infrastructure elements for performance testing as described in this or other Supplement. The Contractor must provision and provide as required by the State and to adhere to the specified Service Level Agreements outlined herein, in keeping with contemporary configurations as required by the specified Service Level Agreements.

The Contractor is responsible for the specification, installation and operation of all code/release version management tools and software as it relates to any release, patch, update or upgrade to State production environments. The Contractor will not be responsible for such tools for SDLC projects performed by the State or 3rd parties as it relates to pre-production environments that are specific in nature to a development project. The State maintains a code/release management tool for LMP environments (Microsoft Team Foundation Server).


of 118

6.4. Periodic Technology Refresh and Update Support Services

6.4.1. General Technology Refresh Obligations

The Contractor is required to become familiar with the current State IT environment as it relates to the LMP application (inclusive of hardware, network, software, infrastructure, security, back-up and other ancillary technical components as required for the State to develop, operate and maintain the LMP system) and agrees, in concert with performing the Services under this Work Area to ensure that the Contractor understanding of this environment is in-keeping with the State’s use of the system.

Upon the State’s written request (generally coincident with hardware and storage technology refresh or update periods as determined by the State), the Contractor must develop a plan to upgrade the existing environments as required by and mutually agreed to with the State, including supporting the State’s refresh of all technology elements during the term. The term ‘technology elements” means all State, infrastructure elements including but not limited to: computer servers; storage; network equipment; security elements and appliances; and related operating systems, microcode, BIOS and other OEM provided software and hardware elements as required to develop, operate and maintain the LMP solution as utilized by the State and as to comply with all previously agreed scopes of work and service levels.

6.4.2. State Acceptance Testing of Technology Refresh

The Contractor must present a detailed plan for both the State and Contractor to review and execute that is specific to the technology element(s) being refreshed and a set of recommendations as to the nature and scope of testing that the State should perform in order to validate that the system functions correctly following the replacement or refresh of technology elements. This detailed testing plan must include (but may not be limited to):

Test Scope (e.g., authentication, business logic, data, reports, interfaces, scheduled and ad-hoc jobs, State extensions etc.,)

Recommended level of testing (e.g., validation, localized acceptance testing, full regression testing, system processing comparisons, data comparisons, spot checks etc.)

Test timing, duration and scheduling considerations

Anticipated State resources required (with high level skill sets) to successfully execute and complete the recommended testing

Testing remediation processes

Final Acceptance Criteria

Other items deemed as required by the State or Contractor in consideration of the detailed testing plan

6.4.3. Technology Refresh - Service Interruptions and Reversibility Plan

As part of the technology refresh terms above, the Contractor must work with the State to minimize any service interruptions to the State and develop a mutually agreeable outage schedule that factors the then-current processing, business cycle or State critical operations requirements in a plan designed to avoid any unscheduled, unplanned or not approved outages to the State that would adversely impact the ongoing operations of the system.


of 118

Additionally, the Contractor must support the State’s development of a contingency plan to address service interruptions which includes a reversibility plan to “roll back” or resume operations on existing State hardware elements that comprise the solution, in part or in full as applicable, to ensure that due to any unforeseen issues associated with the technology upgrade, State operations can resume until such time as the issue is corrected and the technology refresh can resume or complete. The Contractor must support the State’s decision making regarding not decommissioning State hardware until such time as both parties agree that the refreshed technology is performing under mutually agreeable conditions and that State operations are not placed at risk or in jeopardy. The Contractor must support the State to help ensure that, in addition to the above, that the State’s disaster recovery capability is ready to address and perform under any irreversible or catastrophic conditions that may arise associated with, or concurrent with, the technology refresh.


of 118

7. Identified Major ProjectsImportant Offeror Note: Offerors, as part of their RFP response, must provide a detailed response to sections 7.1 (“Next Upgrade”) and 7.2 (“Azure Migration”) and include:

Offeror Experience with similar projects in scope, scale and complexity;

An “ordering” of these projects – for example: upgrade first, cloud migration second; vice-versa; or accomplish both projects concurrently – and include the rationale, approaches, project factors, complexity, risk and other facets that will better inform the State’s understanding of these projects within the context of the overall offeror proposal;

Sample project plan(s), team member experience(s) and other project delivery artifacts as to convey to the State that the offeror is capable of successfully performing the work; and

Any offeror methods, experiences, tools, accelerators or materials that could accelerate, minimize risk, maximize quality or shorten project duration or otherwise shorten State participation and costs.

7.1. Microsoft Dynamics “Next” Upgrade

Microsoft has recently released a new Azure-based Dynamics AX platform (Dynamics 365), and the State believes in the future will continue to invest in the Dynamics AX platform as to result in continued enhancements to the product, future feature/functions, scope, enhancements, extensions and integrations and the like. Due to the LMP implementation and deployment schedule that was recently completed to all State stakeholders (June 2017) the State implemented LMP on a version of AX that was the most current major release at the start of the LMP project in 2015/16 (Version Dynamics AX 2012 R3 CU10). However, the State seeks to continue with the use of AX for the foreseeable future and leverage advancements in the platform as made generally available to all Microsoft customers using AX.

Due to the changes to the technical environment, and anticipated changes to underlying State processes and procedures, the Dynamics “Next” Upgrade will be scheduled with the Contractor at a mutually agreeable time to complete no later than June 30, 2019.

This upgrade must be scheduled in such a manner as to:

minimize disruption, capital requirements and risk to the State ;

balance Contractor staffing availability, State personnel and overall management synergies; and

affect, to the extent possible, a seamless and overall consistent upgrade approach.

The Contractor must propose binding fixed pricing for performance of this upgrade in keeping with the timing considerations outlined herein that is applicable to the overall term of the agreement. To the extent possible, and based on the State’s current understanding of the underlying LMP software elements, the Contractor must propose the upgrade encompassing AX with considerations to including other work contained in this Supplement (e.g., Azure Migration and then current projects) as a bundle to help minimize Project Management overhead and multi-project State oversight.

The State seeks to pursue opportunities to improve upon the current LMP by utilizing delivered AX functionality and standardizing business processes across State stakeholders where applicable. Continued Standardization of


of 118

business processes and utilizing delivered functionality provides the State leverage to incorporate more capabilities within AX, taking greater advantage of the investment in the platform.

7.1.1. General Contractor Responsibilities

Based upon the defined scope of the project, the State requires the selected Contractor to lead and execute all phases of the Systems Development Lifecycle and at a minimum for the areas identified below:

State LMP 2.0 Platform to Microsoft Dynamics “Next” Fit/Gap Analysis

Business Process Design (in light of fit/gap and State identified process improvements)

Technical Design

System Development inclusive of all State RICEFW elements, Agency devices (POS/Scan/Payment), Warehouse Devices (Scan/Pick/Inventory Management) and retrofit or replacement (functional and technical equivalence) State customizations;

System and Performance Testing

Production Cutover Management

Post Implementation/Go-Live Support

Organizational Change Management

Infrastructure Validation and Readiness

7.1.2. Current Environment: Reference Information

The following information and statistics are provided to aid offerors in understanding the current scope of LMP. Additional materials that may be of assistance are provided in the Section 13 of the RFP.

The State maintains documentation outlining the design and objects associated with existing modifications for reports, online customizations, and interfaces that will be reusable for the upgrade effort to support the reapplication, upgrade or modification of these modifications.

7.1.3. Upgrade Planning Requirements

As part of planning, designing and implementing the Major upgrade to LMP the following planning requirements must to be incorporated into the overall Contractor pricing and included in the set of requirements. The Contractor must 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 AX modules must be on Microsoft’s then current supported version listing). As contained elsewhere in this Supplement, the State has contracted to provide current underlying hardware and software infrastructure elements to serve the Contractor’s upgrade efforts.

The Contractor, prior to initiating upgrade work using these infrastructure platforms, must conduct a review of the environment and identify any deficiencies to the State that need to be addressed by the State or the State’s contracted infrastructure upgrade/refresh vendor.

Upgrade planning must factor any regularly scheduled batch processing or system availability as well as any seasonal processing requirements (e.g., holidays, end of year processing, financial closes, etc.) and


of 118

should be scheduled to maintain compliance with system availability as specified under State SLAs and in consideration of the then prevailing Run-Book or production schedule.

The Contractor must lead the assessment of the final requirements for the upgrade in order to develop a detailed understanding of the State’s requirements and to serve as the basis for the effort and ongoing scope/requirements control;

The Contractor must specify the number and configuration of environments required for the upgrade to be provided by the State;

The Contractor is responsible for the design, development, and implementation of the upgrade in provided State environments (this includes requirements/design discussions, design review/signoff, document design specification, document and execute unit and integration/interface tests, and support business in executing their UAT);

The Contractor must provide application, database and operating system technical support services required for the upgrade (e.g., tuning the performance, integrating with State technical infrastructure) on State provided environments during the upgrade project.

All upgrade activities must be performed in accordance with the appropriate software development lifecycle procedures in this RFP and follow industry standard version, code and release control processes as well as a structured release processes described in Section 6 of this Supplement.

For all code based deliverables that are accepted by the State or otherwise placed in commercial use, the Contractor must promptly provide an electronic copy of all source code elements to the State.

Notwithstanding Major Upgrade enhancement requirements as outlined above, the Contractor has an obligation to design, implement and maintain all system elements in keeping with the 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 warranty, support, performance and ongoing upgradeability of underlying software, hardware and ancillary elements of the Managed Service.

7.1.4. RICEFW Changes

The LMP Upgrade project provides opportunities to utilize delivered functionality to achieve improved business results. The State will provide existing design documents capturing the current state of the system, including functional and technical designs for RICEFW objects to be carried forward from the Upgrade. The scope of the Design Phase is to provide comprehensive documentation (Detailed Designs) of the functionality changes as part of the Upgrade program. The State expects the Contractor to validate the disposition placed on each object during the design phase. Offerors should expect that minor changes may occur from the list provided with this RFP and factor these changes as part of their approach and cost response. The Contractor must make a final assessment on each object as a function of the design phase, but nonetheless must be done with the State’s approval. All RICEFW list objects must include a detailed design document created or updated and signed off by the State. Contractor is responsible for migrating, retrofitting (if required) and documenting all custom objects in the Upgrade.

The Contractor must create and seek formal State Acceptance on the following deliverables during the Upgrade Project:

Deliverable 10. Proposed Work Breakdown Structure (WBS)


of 118

This document is a hierarchical decomposition of the project into phases, deliverables and work packages. In the work breakdown structure supplied, sufficient detail needs to be presented and maintained over the course of the project to track the earned value against the Contractor proposed costs and work efforts.

Deliverable 11. Resource Plan The resource plan must specify resources required, by type, over the duration of the

project. Contractor must identify all required resources (Contractor, State or otherwise) to complete the project, except where otherwise specified in this document, and include all costs for those resources that are to be provided by the Contractor. Sample roles should be inclusive of Developers, Business Analyst, System Administrator, Security Analyst, Database Administrator, or any other roles deemed necessary by the Contractor.

Deliverable 12. Project Timeline This timeline specifies key milestones and phases. Contractor should factor the State’s

fiscal year end on June 30 and key business seasonal periods related to holidays and November/December volume increases. The Contractor must include planned dates for the following project milestones, but not limited to: Availability of all System Environments; Development Complete; Code Freeze; All Key Testing Dates; UAT Testing Begin and End Dates.

Deliverable 13. Communication Plan This specifies typical project stakeholders, communication frequency, and

communications vehicles. It must also include the approval process for communications, and how the approval process may differ based on target audience.

Deliverable 14. Application Architecture This is the application architecture that must be used during the project. This architecture

must show all components, how various systems interrelate, as well as migration paths between systems.

Deliverable 15. Capacity Plan This document(s) specifies by phase and system the sizing, CPU, and memory. This

document must account for the various steps of the system upgrade, data conversion, all testing phases, and steady state production/non-production.

7.1.5. Design Phase Requirements

At a minimum the following deliverables are required from the Contractor during the design phase of the project.

Deliverable 16. Batch Analysis and Design This document must include the approach to analyzing the batch flow and job flow

diagram for all batch jobs, new, unchanged, and modified. The State will provide documentation of the current batch flow to the selected Contractor.

Deliverable 17. Application Design All RICE list objects must include a detailed design document created and signed off by

the State. The design document format will be agreed to as part of the project. Refer to Section 13 for the listing of objects from the compare of Production LMP AX to Demo AX Next.

Deliverable 18. Security Design


of 118

This document must define the security roles, approach for security management and testing strategy for security. Security design must be compliant with all State requirements.

Deliverable 19. Change Control Approach This document must explain the approach for performing change control of identified

objects, both those required as well as those deemed unnecessary. This must also include the required communications and coordination points for properly obtaining sign-off’s and authorizations.

7.1.6. Build Phase Requirements

At a minimum the following deliverables are required from the Contractor during the Build phase of the project.

Deliverable 20. Training Plan and Training Needs Assessment This document must define the training approach, requirements, and plan for creation and

delivery. It must document the results of the training needs assessment and the approach to execution.

Deliverable 21. Test Plan This document defines the testing approach, including the phases, entry and exit criteria. It

must also document the approach for managing defects.

Deliverable 22. Requirements Traceability Matrix Confirmation that all State Requirements inclusive of State RICEFW elements in their

entirety have been included in the upgrade and are ready for Contractor System Testing and State Acceptance Testing

7.1.7. Test Phase Requirements

At a minimum the following deliverables are required from the Contractor during the test phase of the project. The testing cycles and types required for the project to be successful include, but are not limited to:

Technical Architecture Connectivity Testing

Unit Testing

Upgrade Test Move to Production

System Integration Testing

User Acceptance Testing

Deliverable 23. Cutover Management Plan This document must identify the series of tasks to be performed in the appropriate

sequence to ensure production readiness. This plan must also explain the approach for business continuity during and after cutover.

Deliverable 24. UAT Test Results These documents are the presentation of the results from a particular testing phase. If

different formats are indicated given the purpose of particular test phases, this must be explained as well.


of 118

7.1.8. Deployment Phase Requirements

At a minimum the following deliverables are required from the Contractor during the deployment phase of the project.

Deliverable 25. Configured, Tested and Tuned LMP Utilizing AX Next (Production Acceptance) Acceptance of the State deployment checklist for Production and Non-Production

environments.

7.1.9. Project Completion Activities and Final Documentation

Following ninety (90) days of successful execution by the Contractor Managed Service in the production environment, the Contractor shall be relieved of Project requirements contained within Section 7, however all Steady-State Run requirements remain in full effect. During the 90-day period immediately following the introduction of the upgraded LMP to production the Contractor must:

Ensure adequate staffing from the Contractor Project Team is on hand (or available remotely) to ensure that during this 90 day period all Service Level Agreements committed to by the Contractor in this RFP are adhered to, specifically:

Prompt isolation, triage and repair of any Severity 1 or 2 issues;

Performance Monitoring of the System to ensure that there are no statistically significant (i.e., +5%) deviations from actual production performance as compared to the results of the upgrade performance test(s);

All interfaces, ETLs and RICEW objects perform and function as specified;

Work with the State to review system and database performance statistics that may indicate either or both of infrastructure configuration or LMP / AX configuration issues and work with the State to remediate these issues;

Monitor job schedules and job execution inclusive of results to ensure that the job scheduling system is performing and functioning correctly

Compile all final versions of the upgrade documentation, work products and delivery materials and locate / organize them as ‘FINAL’ on the State provided SharePoint site.

Deliverable 26. Final Acceptance Obtain a final acceptance document from the State and the Contractor Managed Service

Team confirming that all of the above has been delivered and accepted as final.

If, during the 90-day period immediately following the introduction to Production, a Severity 1 issue occurs that can be directly attributable to the efforts of the Contractor, and not the State’s infrastructure team, the Contractor Managed Service Team or other non-Project parties, the 90-day period will, at the sole discretion of the State, be reset for additional 90 day periods until such time as the system can perform without Severity 1 issues.

7.2. Microsoft Azure Migration (Production and/or DR)

The State seeks (pending a better understanding of the merits, economics, operating/technical efficiencies and a variety of other factors) to migrate the on premise based LMP system to utilize Microsoft’s Azure Cloud as part of the managed service.


of 118

This effort may be included in part of an upgrade to Dynamics AX 365, however, should the State elect not to complete a version upgrade during the time period identified in Section 7.1, the Contractor must proceed with a plan to migrate the current infrastructure to the Azure environment.

A general set of motivators that inform the State’s strategy include:

Access to scalable, on-demand based computing models that support the continued growth of Ohio’s liquor enterprise as well as seasonal fluctuations in processing requirements (e.g., major holidays, end-of-year and other exceptional processing);

Business agility in creation, use and elimination of system environments associated with projects, enhancements, testing, deployment, prototyping, and the like associated with the ongoing maintenance and operations of LMP;

More available access to DR/fault tolerant processing options associated with cross-cloud computing (e.g., Azure primary, Azure alternate); and

A unified patch, support and security model that is as up to date as the State’s 24x7 operation requires.

Conceptually this “Azure Cloud Migration Project” is as follows:

Azure Cloud (Alternate/DR)Azure Cloud (Primary)

State Data Center (SOCC) State DR Center (Ohio)

Production Environments

Non-Production Environments

DisasterRecovery

Environments

Backup / Restore Services

Current Solution Architecture (Conceptual)

Production Environments

Non-Production Environments

Disaster Recovery

Environments

Backup / Restore Services

End-State Architecture (Conceptual)

Warehouse Logistics AgenciesState Stakeholders

State Network

Azure Cloud Migration Project

The Contractor must work with the State Project to coordinate the meetings and discussions that are required to initiate, execute and thereafter support the project lifecycle activities. Work for each project lifecycle step must be completed in its entirety (i.e., activities, work products and all deliverables accepted) prior to work commencing in subsequent lifecycle steps.

The Contractor’s migration methodology must include and the Contractor must utilize steps for:

Migration Plan

Detailed test plan – System Test, Integration and Performance test

User Acceptance Test

Knowledge Transfer


of 118

Final Deployment

Post Deployment Support

During this Project the Contractor will be responsible for producing the following deliverables to the State:

Deliverable 27. Proposed Work Breakdown Structure (WBS) This document is a hierarchical decomposition of the project into phases, deliverables and

work packages. In the work breakdown structure supplied, sufficient detail must be presented and maintained over the course of the project to track the earned value against the Contractor proposed costs and work efforts.

Deliverable 28. Resource Plan The resource plan must specify resources required, by type, over the duration of the

project. Offeror must identify all required resources (Contractor, State or otherwise) to complete the project, except where otherwise specified in this document, and include all costs for those resources that are to be provided by the Contractor. Sample roles should be inclusive of Developers, Business Analyst, System Administrator, Security Analyst, Database Administrator, or any other roles deemed necessary by the Contractor.

Deliverable 29. Project Timeline This timeline specifies key milestones and phases. Contractor should factor the State’s

fiscal year end on June 30. The Contractor shall include planned dates for the following project milestones, but not limited to: Availability of all System Environments; Development Complete; Code Freeze; All key Testing Dates; UAT Testing Begin and End Dates.

Deliverable 30. Communication Plan This specifies typical project stakeholders, communication frequency, and

communications vehicles. It must also include the approval process for communications, and how the approval process may differ based on target audience.

Deliverable 31. Capacity Plan This document(s) specifies by phase and system the sizing, CPU, and memory. This

document must account for the various steps of the system upgrade, data conversion, all testing phases, and steady state production/non-production.

7.2.1. Azure Cloud Design/Build Requirements

During this phase of the Project the Contractor is responsible for producing the following deliverables to the State:

Deliverable 32. Requirements Validation and Document Build a scalable, environment that supports systems environments included in this

Supplement;

Integration of State, Stakeholder, Supply Chain and Agency Applications & Services:

Authentication via the DAS/OIT ID Domain and Single Sign On for all users.

Requirements Traceability Matrix inclusive of business, functional, technical and process requirements that comprise the scope of the then current LMP system.

Environment capacity plan inclusive of growth and seasonal processing requirements.


of 118

Develop detailed test plans for migration validation and support of cut-over decision making by the State.

Deliverable 33. Solution and Technical Design Document(s) Logical development, logical test and logical environments for each stakeholder group.

Definitive production and DR space sizing;

Architecture should be designed for high availability

The Contractor must provide Azure instance specifications based on the LMP requirements

Identify, document and work in conjunction with DAS/OIT to resolve any network (e.g., IP addresses, domain, name/numbering, firewall) or SharePoint server specific items (e.g., administration, user management, identities, roles and permissions) that may arise.

In parallel with the above, and under the supervision of the State, the Contractor must configure, deploy and perform system testing functions to demonstrate to both DAS/OIT and Commerce that the migration must not adversely impact day-to-day operations nor result in any loss of data. The Contractor must design, implement and migrate services to the new environment by using DAS/OIT’s provided Technical Infrastructure (collectively: servers, storage, networking, software licenses, and identity/security/role information).

Deliverable 34. Configure, Deploy and Migration of LMP, AX, Application, Database, Operating System and Ancillary Software

Migrate all data, configuration values and data, business rules, processing logic, views and reports and RICEFW objects implemented as part of the LMP.

Migrate any Microsoft or 3rd Party companion tools as identified to the DAS/OIT Azure Service.

Document all test results and remediate all defects prior to the commencement of any State testing.

7.2.2. Test Phase Requirements

At a minimum, the following deliverables are required from the Contractor during the test phase of the project. The testing cycles and types required for the project to be successful include, but are not limited to:

Technical Architecture Connectivity Testing

Unit Testing

Test Move to Production

System Integration Testing

User Acceptance Testing

Deliverable 35. Cutover Management Plan This document must identify the series of tasks to be performed in the appropriate

sequence to ensure production readiness. This plan must also explain the approach for business continuity during and after cutover.

Deliverable 36. UAT Test Results


of 118

These documents are the presentation of the results from a particular testing phase. If different formats are indicated given the purpose of particular test phases, this must be explained as well.

7.2.3. Deployment Phase Requirements

At a minimum the following deliverables are required from the Contractor during the deployment phase of the project.

Deliverable 37. Configured, Tested and Tuned LMP Utilizing Azure Cloud (Production Acceptance) Acceptance of the State deployment checklist for Production and Non-Production

environments.

7.2.4. Project Completion Activities and Final Documentation

Following ninety (90) days of successful execution by the Contractor Managed Service in the production environment, the Contractor shall be relieved of Project requirements contained in this Section, however the Steady State Run requirements will remain in full effect. During the 90-day period immediately following the introduction of the migrated LMP to Azure the Contractor must:

Ensure adequate staffing from the Contractor Project Team is on hand (or available remotely) to ensure that during this 90-day period all Service Level Agreements committed to by the Contractor in this RFP are adhered to, specifically:

Prompt isolation, triage and repair of any Severity 1 or 2 issues;

Performance Monitoring of the System to ensure that there are no statistically significant (i.e., +5%) deviations from actual production performance as compared to the results of the upgrade performance test(s);

All interfaces, ETLs and RICEW objects perform and function as specified;

Work with the State to review system and database performance statistics that may indicate either or both of infrastructure configuration or LMP / AX configuration issues and work with the State to remediate these issues;

Monitor job schedules and job execution inclusive of results to ensure that the job scheduling system is performing and functioning correctly

Compile all final versions of the upgrade documentation, work products and delivery materials and locate / organize them as ‘FINAL’ on the State provided SharePoint site.

Deliverable 38. Final Acceptance Obtain a final acceptance document from the State and the Contractor Managed Service

Team confirming that all of the above has been delivered and accepted as final.

If, during the 90 day period immediately following the introduction to Production, a Severity 1 issue occurs that can be directly attributable to the efforts of the Contractor, and not the State’s infrastructure team, the Contractor Managed Service Team or other non-Project parties, the 90 day period will, at the sole discretion of the State, be reset for additional 90 day periods until such time as the system can perform without Severity 1 issues.

Deliverable 39. ITIL-based Implementation and Operations Guide


of 118

The Contractor must provide an update to all Implementation and Operations Guide inclusive of configuration details and ongoing Operations for the support of ongoing operations that is suitable for the State to use thereafter for subsequent projects and operation of the system.

7.3. Future Projects, Enhancements and System Evolutions

The State may from time-to-time request statement of work (SOW) proposals in the form of Interval Deliverable Agreement (IDA) for future Work e.g., Change Request/Amendments under this Contract for the design, development, testing and deployment of new applications or significant application enhancements (“Application Development Projects”). Such projects will be governed by and provided by the Contractor under the standards and requirements contained in this Work Area.

7.3.1. Future LMP Projects and Deployments: Contractor Support Requirements

The State has invested in the creation and ongoing operation of the LMP platform. As a result of ongoing Dynamics AX and LMP releases, stabilization and extension into business areas and services as well as current State efforts underway, the State has identified possible opportunities for the agency to leverage the LMP application in support of its mission.

The Contractor must support the State in:

The development and refinement of ongoing Business Roadmaps for State identified LMP opportunities;

Creation of business case, change programs and LMP adoption/extension budgets, timelines and investment models that are pragmatic and grounded in the realities of budgets, implementation efforts and LMP capabilities;

Development and delivery of exploratory workshops with customer groups who use the system;

Leading of “change agent” type communications designed to encourage State and Statewide adoption of LMP supported service offerings; and

Support State management in bridging: business, functional and technical and organizational changes to propose, design, implement and extend LMP within State.

7.3.2. Development Life Cycle Proposals associated with Development and Enhancement Projects

The Contractor must provide a disciplined Systems Development Life Cycle (SDLC) methodology for use on Application Development Projects and must adhere to such methodology during the performance of Application Development Projects. The Contractor must adapt this methodology as required to meet the State’s needs. The Contractor must 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 Production/Version Control and Release Management requirements must be followed.

7.3.3. Future Project Services Pricing Response and Rate Card

For any Project that performs under a Time and Materials or Staff Augmentation model, the Contractor must utilize the Contractor Rate Card, by project personnel role and experience level as well as Business,


of 118

Functional and Technical role and experience level that is binding over the Contract term. The Contractor may not propose rates in any Project SOW that exceed from this rate card as allowed under any statement of work arising from this contractor.

For any Project that performs under a Milestone or Deliverable based model, the Contractor must provide the State, as part of its proposal all applicable milestones and deliverables, agreed to timing of such milestones and deliverables as well as a firm fixed price for the Project as a whole, inclusive of all such applicable milestones and deliverables.

7.3.4. Submission and Acceptance of the Proposed Contractor Offer and Statement of Work associated with a Future Project

At the State’s request, the Contractor may provide proposals to the State that addresses the State’s requirements 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 as mutually agreed with the State. At a minimum, the Contractor’s offer must include a list of activities to be executed and deliverables to be created, organized by SDLC Phase (e.g., design, build, test and implement).

The Contractor’s offer must be priced based on the either the Rate Card (for time based projects) or Fixed Price Deliverables/Milestones included in the Cost Summary for the completion of the deliverables required by the State’s requirements and as contained in a mutually agreeable Statement of Work (SOW).

The State will review the Contractor’s offer and provide feedback as needed to the Contractor within thirty (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.

Upon State acceptance of a Contractor Proposal, all standards, conventions and general Project Management requirements contained in this document shall apply unless otherwise agreed to in writing by the State.

7.4. Major Projects, Enhancements, Upgrades and Program Support – Service Level Agreements

The State’s specifications pertaining to project performance based on Service Level Agreements (SLA) to be established between the Contractor and the State are applicable to any work associated with the development, configuration, extension or implementation of any software (asset or cloud-based) associated with this document.

These requirements comprise the State’s minimum expectations framework pertaining to project delivery factors, requirements relating to service level commitments, and the implications of meeting versus failing to meet the requirements and objectives, as applicable. These SLAs pertain to any Project Implementation Project and to all subsequent Project related services and phases that are contracted under future Statements of Work between the State and the Contractor related to this document.

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.


of 118

7.4.1. Service Level Specific Performance Credits

Each 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.

The Contractor agrees that in each month of the Contract, 12% of the monthly project charges (MPC) associated with an Implementation Project arising from this contract will be at risk. MPCs are the charges for the deliverables required by the State in such a project that are presented to the State for acceptance during a given month. The MPC for the Project 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.

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.

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 any Implementation Project.

7.4.2. Monthly Service Level Report

On a State accounting monthly basis, the Contractor must 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.

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


of 118

7.4.3. Service Level Commitments – Project Implementation Services

The Contractor must meet the Service Level Commitment for each Service Level set forth in the tables and descriptions below:

No Service Level Agreement Support HoursRequired

Response Resolution

1 Defect Resolution – Severity 1 Items 7x24 Every 4 hours until resolution <= 24 hours

2 Defect Resolution – Severity 2 Items 7x16 Every 8 hours until resolution <=72 hours

3 Defect Resolution – Severity 3 Items 5x9 Every 24 hours until resolution <= 7 calendar days

4 System Test Execution Exit Quality Rate - See specification below -

5 Blocking Issues Identification and Removal 7x24 Every 2 hours until resolution or agreeable workaround is implemented <=10%

6 Regression Testing Performance Issue Find/Fix Rate - See specification below -

7 Project Performance – Milestone Date Delivery - See specification below -

8 Deliverable Acceptance - See specification below -

9 Development Methodology Compliance - See specification below -

10 Issues Detected and Resolved in Production - See specification below -


of 118

7.4.4. Defect Resolution – Mean Time to Repair/Resolve (Severity 1 Items)

Specification: Defect Resolution – Mean Time to Repair/Resolve (Severity 1 Items)

Definition: Mean Time to Repair (Severity 1 Items) will be calculated by determining time (stated in hours and minutes) representing the statistical mean for all Severity 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. “Severity 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.

Formula: Mean Time to Repair (Severity 1 Outages)

=

(Total elapsed time it takes to repair Severity 1 Defect Service Requests)

(Total Severity 1 Defect Service Requests)

Measurement Period: Month

Data Source: Monthly Project Report

Frequency of Collection: Per Incident

Service Level Measures

Individual SL State

Mean Time to Repair (Severity 1 Defects).

Green <=24 hoursYellow >24 hours and <= 48 hours

Red >48 hours


of 118



Definition: Mean Time to Repair (Severity 2 Items) will be calculated by determining time (stated in hours and minutes) representing the statistical mean for all Severity 2 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. “Severity 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.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.

Formula:

Mean Time to Repair (Severity 2 Outages)

=



Measurement Period: Accounting Month




Individual SL State


Green <=72 hoursYellow >72 hours and <= 90 hours

Red >90 hours


of 118



Definition: Mean Time to Repair (Severity 3 Items) will be calculated by determining time (stated in hours and minutes) representing the statistical mean for all Severity 3 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. “Severity 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 identified 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 Severity 1 or Severity 2 Defect.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.

Formula:

Mean Time to Repair (Severity 3 Outages)

=







Individual SL State


Green <= 7 calendar daysYellow > 7 calendar days and <= 10 calendar days

Red > 10 calendar days


of 118

7.4.7. Service Levels – 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 Severity), 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 Severity 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 for all releases, updates, enhancements or patches and as a result of any production or commercial use the initial Service Level will be 95%. The initial measurement period will be as mutually agreed by the Parties, not to exceed three months and only pertain to the first production release.

Formula

Test Quality Exit Rate =

(Total # of Test Scripts Passed during Final Pass of System Test)

(Total # of Test Scripts Executed during Final Pass of System Test)

X 100



Frequency of Collection: At end of System Test


Individual SL State System Test Execution Exit Quality Rate

Green >= 90%Yellow >= 85%, <90%

Red < 85%


of 118

7.4.8. 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 halted, delayed or 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 or timely 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% 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 lost to blocking issues

=

(Total Test Time Lost to Blocking Issues)

(Total Scheduled Test Time)X 100





Individual SL State

Blocking Issue Identification and Removal

Green <= 10%Yellow >10%, <= 12%

Red <= 15%


of 118

7.4.9. 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 UAT testing 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 in the 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.“Time spent in Regression Fix” is the development time required for fixing UAT defects which cause UAT testing to stop or be delayed past the scheduled test completion date. The sum of this time is then rounded (using standard rounding) to result in the number of days.“Time spent in Regression Test” is measured as the number of days that are added to the original UAT Test schedule due to test defect or issue resolution and additional testing having to occur due to regression testing of identified UAT defects. “Total Development Time for Release in Days” is measured as the total time for the Release prior to the UAT phase for development and systems testing activities performed by the Contractor. Should issues be identified and resolved within the planned UAT period, this SLA will not apply.

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



Frequency of Collection: At end of UAT phase for each release to Production


Individual SL State Issue Find/Fix Rate

Green <= 10%Yellow >10%, <= 12%

Red <= 15%


of 118

7.4.10. Service Levels – Project Performance, Milestone Attainment

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. Contractor 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 Number of Contractor Milestones met within the measurement month

Total Number of Contractor Milestones planned to be met during the measurement month per the agreed upon list of milestones

X 100

Measurement Period: Monthly, During Project

Data Source: Weekly Project Report

Frequency of Collection: Weekly


Individual SL State % Compliance Milestone Dates

Green > 90%Yellow > 85%, <=90%

Red <= 85%


of 118

7.4.11. 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 document 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.This SL will commence upon Project initiation and will prevail until Project completion.

Formula:

% Deliverable Acceptance

# Deliverables Accepted During Period (less the State review Time)

# Deliverables Presented during PeriodX 100





Individual SL State % Deliverable Acceptance

Green > 85%Yellow > 80%, <=85%

Red <= 80%


of 118

7.4.12. Service Levels – 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





Individual SL State % SDLC Compliance

Green > 95%Yellow > 90%, <=95%

Red <= 90%


of 118

7.4.13. Service Levels – Phase 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 Time Required to Resolve Issues Identified During initial 90-day production Period

Total Hours included in a Production ReleaseX 100





Individual SL State

Issues Detected and Resolved in Production

Green <= 2%Yellow > 2%, <=3%

Red > 3%


of 118


of 118

8. Contractor Staffing RequirementsAs this service is an offering supported by Commerce and includes OIT participation in the infrastructure identified herein, the following table represents the State’s minimum commitments to this Service. Should, based on the experience of the offeror additional roles be required of the State, the offeror must identify these roles, provide rationale and include a summary description of the skills and competencies required for each position. Note all roles (State minimum or otherwise) must be included in the offeror Staffing Plan as required in this section of the Supplement. For all State roles marked “as required” offerors are to include (within their proposal) the staffing level required of the State to ensure that the Contractor project is supported adequately.

The State will provide a dedicated State Project Lead to serve as the Contractor’s day-to-day point of contact for the Service. This role must be staffed throughout the duration of the Contract. The State Service Lead will facilitate process and policy decisions in support of the Contractor.

8.1. Work Location(s) and Contractor Personnel Involvement

As part of the offeror response, the Contractor must provide a summary of full time equivalent (FTE) personnel needed for State service delivery and space planning considerations that includes completion of the following table:

The values in this sample table are for illustration purposes only, Offerors are to remove these illustrative artifacts and populate the table based on their proposed team and work locations. Rows may be added by offerors.

Contractor Proposed Role(s)

% of FTE Time Spent at State Work

Location

% of FTE Time Spent at Contractor

Work Location Engagement Period

MANAGED SERVICES ROLES

Contractor Account Representative 20% 20% Contracted duration

Operations Service Lead 100% Contracted duration

Financial Systems Lead 100% Contracted duration

Dynamics/AX Technical Lead 100% Contracted duration

SQLServer, Windows/OS and Infrastructure Liaison 100% Contracted duration

Technical Architect 50% Contracted duration

L2/3 Service Desk Lead Periodic 100% Contracted duration

Performance Tuning Expert Periodic, 10% Periodic, 20% Contracted duration

Service Desk Technician (1) – Onsite 100% Contracted duration

Service Desk Technician (4) – Remote Periodic 50% Contracted duration

Production Change Manager Periodic 100% Contracted duration

… etc … Contracted duration

TRANSITION ROLES (from State to Contractor)

Transition Executive 100% - 7/1/14 – 12/31/14

Transition Managers (FIN, HR, Other) (3) 100% - 7/1/14 – 2/1/15

Functional SME (10) 80% 20% 7/12/14 – 12/15/14

… etc…

FTE time must represent those hours in direct support of State Business. In some cases this number may be less than 100%.


of 118

The offerors Service Staffing Plan and Time Commitment response must contain the following information:

An organizational chart including any subcontractors and key management and administrative personnel assigned to this project.

A contingency plan that shows the ability to add more staff if needed to ensure meeting State requirements.

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

Key Service Personnel

In addition, the offeror’s proposal must identify all Key Service Personnel who will provide services as part of the resulting Contract. The Key Service Personnel are identified in each applicable Supplement. The State expects that the proposed named Key Service Personnel will be available as proposed. Resumes for the proposed candidates must be provided for all Key Service Personnel. Representative resumes are not acceptable. The resumes will be used to supplement the descriptive narrative provided by the offeror regarding their proposed team.

The resume (2-page limit per resume) of the proposed Key Service Personnel must include:

Proposed Candidate’s Name

Proposed role on this Service

Listings of competed projects (a minimum of two references for each named Key Project Personnel) that are comparable to this Project or required similar skills based on the person’s assigned role/responsibility on this Project. Each project listed should include at a minimum the beginning and ending dates, client/company name for which the work was performed, client contact information for sponsoring Directors, Managers or equivalent level position (name, phone number, email address, company name, etc.), project title, project description, and a detailed description of the person’s role/responsibility on the project.

Education

Professional Licenses/Certifications/Memberships

Employment History

8.2. Microsoft Dynamics and Platform Element Accreditation and Certification Requirements

Offerors, as part of their proposal, and as Contractor performing the work must include a team with the following accreditation and certification levels as part of their Proposed team. The State acknowledges that a single team member may maintain multiple of these certifications:

Microsoft Dynamics Certifications (or higher, or Dynamics365 equivalent)

Microsoft Platform Element Certifications (or higher)

MB6-701: Microsoft Dynamics AX 2012 R3 RetailMB6-705: Microsoft Dynamics AX 2012 R3 CU8 Installation and Configuration

MCSA/E – SQL 2014 (or Higher) Database AdministrationMCSA/E – Web ApplicationsMCSA/E – Windows Server 2012 (or Higher)


of 118

MB6-890: Microsoft Dynamics AX Development IntroductionMB6-892: Microsoft Dynamics AX Distribution and TradeMB6-893: Microsoft Dynamics AX Financials

(note: A/E are equally acceptable)

8.3. Use of State Provided SharePoint® Collaboration Site, Use of State eMail Exchange®

Starting with the Award of this Contract and the Contractor access being made available by the State, and in conjunction with the delivery of the Services and any Project to the State under this RFP, the Contractor must use the existing State provided and hosted document management and team collaboration capability (Microsoft® SharePoint™) to provide access through internal State networks and secure external connections to all project team members, approved project stakeholders and participants.

In conjunction with the utilization of this tool, the Contractor must:

Structure the document management and collaboration pages and data structures in such a manner as to support the overall requirements of the Project;

Be responsible for the maintenance and general upkeep of the designer configurations of the tool in keeping with commercially reasonable considerations and industry best practices as to not adversely impact the project delivery efforts performed by the Contractor and State; and

At the conclusion of the Contract and any Projects, or upon request of the State, ensure that the State is provided a machine readable and comprehensive backup of the SharePoint® database(s) contained within the tool that is owned by the State and not proprietary to the Contractor or otherwise required by the State to maintain ongoing project documentation and artifacts (i.e., Contractor must remove all Contractor proprietary or non-State owned or licensed materials from the tool).

As a minimum standard, the Contractor must include the following delivery artifacts in the Site:

All Contractor required reports as specified herein to the State and supporting documentation, work products and artifacts produced formally for the State or for State review and approval.

All Systems Development Lifecycle (SDLC) delivery artifacts when accepted by the State in final and editable form (i.e., native formats not PDF or scanned facsimiles) inclusive of requirements, design, technical, functional, performance, results, diagrams, RACI or Roles/Responsibilities, approvals, operational and end-user guides, training materials, analysis, findings, issues, risks, actions and documents as approved by the State in conjunction with the delivery of a Project

All Change to Production or Environment Change Request directives from the State

All approved Change Orders or Change Requests

All Operational, Maintenance, Job Schedules or Run Books

All monthly SLA reports

Any approved customizations, RICEFW objects in a machine readable form as attachments

Any Amendments or Change Orders to this Contract

Meeting Minutes, Resolutions and Issues/Risks

The Contractor must use State email systems for all formal correspondence pertaining to State business, in particular those that may contain or identify sensitive State data, processes, conventions, practices, issues,


of 118

vulnerabilities, risks and project matters or may be considered advantageous to gaining unauthorized access to State systems, infrastructure or data.


of 118

9. Service Establishment Requirements – Transition from Current State to Managed Service

9.1. Overview of Scope

The Contractor must support the migration of all systems, system components, documentation and related operational support roles in transitioning from the State to their Service to enable the Services to be provided under the Scope of Work to the extent defined and agreed within this SOW. The Contractor’s responsibilities with respect to Transition Services include the tasks, activities and responsibilities listed below.

9.2. Service Establishment / Transition Management

During the period beginning on the Effective Date and ending upon completion of all Contractor responsibilities as required in the State and Contractor agreed Transition Plan. The Contractor must plan, prepare for and conduct the migration of LMP systems operations (the “Transition”). Transition must include the migration of systems and related operational support from currently existing facilities, locations and personnel to the Contractor’s responsibility as required by the State herein.


Coordinate with the State and Contractor network provider to schedule the installation of any required secure connectivity into Contractor Service Delivery Center(s);

Implement processes and controls as to not otherwise disrupt the State business operations, including the interfaces between the State and various third-parties;

The State will:

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 periods;

Support the establishment of secure network connections from State facilities to Contractor service delivery or operations center(s);

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

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.

9.3. Service Establishment / Transition Plan

Transition will be conducted in accordance with a written plan (the “Transition Plan”) which must include the following items. The Transition Plan will be created as a deliverable. The Contractor will be 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.

Deliverable 40. The Transition Plan must contain:


of 118

An inventory and description of the IT operations being migrated;

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

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

A detailed schedule of migration activities inclusive of State and Contractor staff (generally Microsoft Project GANTT);

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

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

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

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

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

The State will:

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

Manage State stakeholder-facing efforts and cooperation with agreed Contractor created roles, responsibilities, plans and requirements; and

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.

9.4. Service Establishment / Transition Process

No 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 and operationally performs and is conformant to agreed-upon Service Levels, and has been accepted by the State.

As part of Transition, the Contractor must:

Inventory, track and report all LMP operational software on supported servers.

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


of 118

discrete activities tasks as part of the transition planning process. The State will provide availability of the Project and Commerce Application group to the Contractor according to such agreed-to responsibility matrix in the Transition Plan.

9.5. Service Establishment / Transitioning Planning and Analysis

The tasks and activities to be performed by the Contractor as part of the planning and analyzing phase of the existing computing environment must include the following at a minimum:

The Contractor must be responsible for managing the process and preparing a scope and operations portion of the Transition Plan which must 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.

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

The Contractor must define solution blueprints and operational/technical change plan for each major functional or service domain areas (e.g., environments, code and software versions, interfaces, RICEFW objects, Dynamics, customizations etc.).

The Contractor must conduct weekly progress reviews with appropriate the State personnel.

The Contractor must 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 must, 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 must be provided; (v) describe any assumptions made in compiling the plan; and (vi) identify any the State dependencies or personnel requirement assumptions.

The Contractor must establish baseline performance levels of supported servers, processes (both online and batch) and other measurable elements of system performance for the current “status-quo” environment to be used as the basis for performance validation prior to the conclusion of the Transition Period.

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

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

9.6. Service Establishment: Service Operations Design-Build Services

The Contractor must develop and build operational, technical and functional designs for each service domain of the systems environment. The environment design and build Services must also include the following:

Service Design


of 118

The build designs must 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:

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 infrastructure if applicable)

Assess current IT solution gaps and dependencies.

Inventory and catalogue IT system/solution designs to support solution requirements including: Design user interaction model which defines applicable standards, solution prototypes, and virtualization designs; reports and forms; integrated solution components and interfaces to external systems; logical environment, data conversions/migrations, processes and procedures as agreed necessary.

Compile and maintain solution incident lists.

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

Service Build

The Contractor is responsible for generating, and thereafter operating and maintaining 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 must 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:

Perform detailed technical design as agreed appropriate.

Inventory and catalog solution components to support approved design specifications as follows: configurations and customized solution elements, interfaces, process and procedures as required; provisioning of solution environments including CPU, disk and memory requirements; and configuration of integrated solution components and interfaces to external systems.

Coordinate with the State Infrastructure Management Team to implement other physical and network environmental requirements and designs.

Document solution and refine applicable user acceptance/validation criteria.

Develop any applicable State-specific Transition training materials, including: perform training needs assessments based on the State requirements that have been identified to the Contractor; Determine the training material/method of delivery design with the State; and provide training material to support the agreed-upon approach and methods of delivery.


of 118

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

Conduct Service build progress reviews with appropriate State personnel.

9.7. Service Establishment - Transition Test/Acceptance.

All supported environments are subject to a formal validation testing and acceptance process as stated in this Supplement, that uses objective and thorough test or validation criteria established by the Parties that will allow the Parties to verify that each element of the Transition meets the specified functional, technical, operational and where appropriate, performance requirements. The testing and acceptance process must be developed for each element of the Transition as soon as possible after confirming and documenting State requirements. The testing and acceptance process must include a capability for tracking and correcting problems. The tasks and activities that the Contractor must perform as part of the testing and acceptance process related to Transition must also include the following:

Provide testing as required to perform acceptance testing work for the Service for supported systems, and where appropriate performance validation testing period. The testing must 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;

Deliverable 41. Transition Testing and State Acceptance Document State approval of solution components and verification of applicable completion

criteria for transition into deployment and production (steady State) use;

Provide the State with reports tracking the progress of the Contractor’s performance of testing work, or in the case of user acceptance testing, support of State activities; and

The Contractor must provide timely responses to State requests for information and reports necessary to provide updates to State business units and stakeholders, as reasonably required.

9.8. Service Establishment - Service Deployment

Following State Acceptance, the Contractor must

Execute required migrations that follow a mutually agreeable and documented process that includes clear roles, responsibilities and review/approval steps for participating parties.

Document incidents and provide to the State for resolution.

Compile and maintain solution incident lists.

Support State deployment communication efforts including identifying required communication recipients and communicate deployment activities to stakeholders.

Evaluate detailed communication feedback from recipients and stakeholders including the effectiveness of and need for additional communication.

Support training activities as mutually agreed in the Transition Plan including confirm timeframe, type, content, and target user audience of planned training.


of 118

9.9. Service Establishment - Staffing Plan and Time Commitment

The offerors Staffing Plan and Time Commitment response must contain the following information:

An organizational chart including any subcontractors and key management and administrative personnel assigned to this project.

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

The number of people onsite at State location(s) at any given time to allow the State to plan for the appropriate workspace. Offeror Note: The following table is provided as an example of what the State expects the offeror to provide in the proposal response for this requirement.

Illustrative Offeror Staffing Plan

Project Week 1 2 3 4 5 6 7 8 9 10 11Phase Startup /

Analyze Design Phase Build Phase Test Phase Deployment Operate

Project ManagementState 3 3 3 3 3 3 3 3 3 3 3

Contractor 2 2 2 2 2 2 2 2 2 2 2Functional FTEs

State 4 4 4 4 4 4 4 4 4 4 4Contractor 8 8 8 8 8 8 8 8 8 8 8

Technical FTEsState Infrastructure 2 2 2 2 2 2 2 2 2 2 2

State Security 1 1 1 1 1 1 1 1 1 1 1Contractor 6 6 6 6 6 6 6 6 6 6 6

Business / Agency FTEsState 4 4 4 4 4 4 4 4 4 4 4

Contractor 2 2 2 2 2 2 2 2 2 2 2Summary Total

State 14 14 14 14 14 14 14 14 14 14 14Contractor 19 19 19 19 19 19 19 19 19 19 19

Offerors are encouraged to add additional roles and responsibilities as appropriate based on their proposed Project Staffing Plan as to highlight the involvement of their Proposed Team and inclusion of State resources in the project to help ensure its success. The number of FTEs depicted in the above table are provided as an illustrative example and in no way connotes State expectations as to the level or involvement of the State or Contractor in this project.

A statement and a chart that clearly indicates the time commitment of the proposed Project Manager and the offeror’s Key Project Personnel, inclusive of the Project Manager and the offeror’s proposed team members for this Work during each phase of the Projects, the System Development Life Cycle associated with Projects, and the commencement and ongoing operation of the within the Service.

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

In addition, the offeror’s proposal must identify all Key Project Personnel who must provide services as part of the resulting Contract. The Key Project Personnel are identified in this Supplement. The State expects that the proposed named Key Project Personnel must be available as proposed to work on the Project. Resumes for the proposed candidates must be provided for all Key Project Personnel. Representative resumes are not acceptable.


of 118

The resumes will be used to supplement the descriptive narrative provided by the offeror regarding their proposed project team.

The resume (2-page limit per resume) of the proposed Key Project Personnel must include:

Proposed Candidate’s Name

Proposed role on this Project

Listings of competed projects (a minimum of two references for each named Key Project Personnel) that are comparable to this Project or required similar skills based on the person’s assigned role/responsibility on this Project. Each project listed should include at a minimum the beginning and ending dates, client/company name for which the work was performed, client contact information for sponsoring Directors, Managers or equivalent level position (name, phone number, email address, company name, etc.), project title, project description, and a detailed description of the person’s role/responsibility on the project.

Education

Professional Licenses/Certifications/Memberships

Employment History


of 118

10. Contract Governance

10.1. Contractor Account Representative

During the Scope of Work Term, the Contractor must 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 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 and commit the Contractor’s firm 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”).

10.2. State Account Representative

During 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”).

10.3. Participation and Support of Service Management Steering and Oversight Committee

The Contractor and the State will conduct 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 document, 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.

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:

Such other meetings of the State and the Contractor personnel, including senior management of the Contractor, as the State may reasonably request.


of 118

For each such meeting, upon the State request, the Contractor must prepare and distribute an agenda, which will incorporate the topics designated by the State. The Contractor must 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 must record and promptly distribute minutes for every meeting for review and approval by the State.

The Contractor must 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.

Open and honest bi-directional feedback as to overall Service performance, Contractor/State working relationships, Contractor personnel matters, replacement or augmentation of Contractor Staff, Contractor support (or lack thereof) of State, State initiatives, opportunities for refinement or enhancement of Services or Service quality and other matters as appropriate.

10.4. Regular Meetings and Conference Calls

Within 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.

10.5. Issue and Dispute Resolution Process

10.5.1. Informal Dispute Resolution

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

If the Parties are unable to resolve a dispute in an amount of time that either Party deems required under the circumstances, such Party may refer the dispute to the Service Management Steering and Oversight Committee 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 Service Management Steering and Oversight Committee, each Party will prepare and submit to the Service Management Steering and Oversight Committee a detailed summary of the dispute, the underlying facts and their respective positions, together with any supporting documentation.

The 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


of 118

dispute. The 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 group. If the Service Management Steering and Oversight Committee is unable to resolve a dispute within thirty (30) days of the first meeting addressing such dispute (or such longer period of time as the Parties may agree upon), either Party may refer the dispute to the State CIO and Contractor Managing Director / Lead Public Sector Partner 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 State CIO and Contractor Managing Director / Lead Public Sector Partner, the State Administrator and Contractor Account Executive will each prepare and submit to the State CIO and Contractor Managing Director / Lead Public Sector Partner a detailed summary of the dispute, the underlying facts and their respective positions, together with any supporting documentation.

If the State CIO and Contractor Managing Director / Lead Public Sector Partner are unable to resolve a dispute within thirty (30) days of the first meeting addressing such dispute (or such longer period of time as the Parties may agree upon), either Party may refer the dispute to internal escalation by delivering written notice of such referral to the other Party.

10.5.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 Administrator and Contractor Account Representative, the disputed matter will be reviewed by the 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 neutral third party 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 to the extent permitted by law. 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 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.


of 118

10.5.3. Escalation for Repetitive Service Level Failures

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

10.5.4. No Termination or Suspension of Services or Payment.

While any dispute is pending, the Contractor must continue its obligations 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.

10.6. Billing and Invoicing

Contractor must provide billing by the fifth business day of each month for the Monthly Recurring Charges associated with Work Area 1, Steady State Support Services, less any fee credits due the State as a result of failure of the Contractor to achieve State required Service Levels.

In support of the monthly billing for Work Area 1, the Contractor must 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 support State payment requirements. 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 must include the Monthly Recurring Charge adjusted by any additional or reduced charges, plus any additional out of scope services incurred during the month.

For those service elements provided by the Contractor under Work Area 2 (Ongoing Enhancements, Upgrade and Program Support) the Contractor must provide sufficient detail as mutually agreed by the State as to support the State’s verification that such Services were performed or delivered by the Contractor and, if applicable, accepted by the State. Such detail may include, depending on the nature of the work: Contractor timesheet(s); Deliverable Acceptance Documents signed by an authorized State representative, milestone attainment or project completion.

The 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.

10.7. Service and Work Effort Reporting

The Contractor must 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 by the State. The Contractor must 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 must 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.


of 118

Within thirty (30) days of Service Commencement, the Contractor must 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.

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 to the various business units and divisions of the State and the other eligible recipients.

10.8. Back-Up Documentation

As part of the Services, the Contractor must 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 must provide the State with all documentation and other information reasonably requested by the State from time to time to verify that the Contractor's performance of the Services is in compliance with the Service Levels and the Work Requirements as agreed.

10.9. Correction of Errors

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

10.10. Annual Service Quality and Scope Review

The Contractor and the State agree to meet no less frequently than on an annual basis to review the then current State use of the system and the Contractor’s support of the State in performing the Services. This meeting will include, but not be limited to:

Contractor Service Levels attained in performing the Services;

Operational performance of the Contractor, and by extension the system, under the Contracted scope of services inclusive of all scope contracted by the State in the preceding years;


of 118

All open or recurring issues between the parties inclusive of incident, problem and change performance, defects and other items that either party deems unsatisfactory;

Anticipated State use, scope and requirements of the Contractor in the upcoming year in light of State priorities, requirements, cost and service scope factors.

Should the State determine that the Contractors performance is inadequate or no longer required in any service scope area(s), the State will notify the Contractor in writing that the Contractor will no longer be required to perform the service scope area(s) and the Contractor shall remove the scope area(s) from the Service and reduce the State’s cost in the following year(s) in keeping with the quoted cost as contained in the Cost Collection Workbook for the applicable scope area(s).


of 118

11. Contract Conclusion Requirements: Transition to Successor/State at Contract Termination or Non-Renewal

11.1. Overview

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

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

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

Contractor must cooperate with the State in its attempts at transferring the services responsibilities another provider in a manner in keeping with not adversely affect the provision of ongoing services.

11.2. Responsibilities

Commencing no less than 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 must 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 must also provide Termination/Expiration 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.


of 118

Contractor will obtain any necessary rights and thereafter make available to the State or its designee, pursuant to agreed terms and conditions, any 3rdParty services then being utilized by Contractor in the performance of the Services, including services being provided through 3rdParty 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 3rd 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 the Contractor will continue to provide Termination/Expiration Assistance. Actions by the 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, the Contractor must provide to the State such information and other cooperation regarding performance of the Services as would be reasonably necessary for the State or a 3 rd Party to prepare an informed option analysis for such services, and for the State or a 3 rd Party not to be disadvantaged compared to the 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).

Contractor will provide State an inventory of resources (or resource full time equivalents) then performing work under the Services statement of work to assist the State in determining the appropriate resourcing and skill model required for the State or a State contracted 3 rd 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 must 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 must be priced utilizing the then current Contractor rate card at the time of the request and as approved by the State.


of 118

11.3. Standards

The 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 3 rd 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 of this document will continue to apply during the agreed Termination Assistance Period.

11.4. Termination Assistance Plan

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

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.


of 118

11.5. Termination Management Team

Contractor 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.

11.6. Operational Transfer

Contractor must 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 and data 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.

Cooperate 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.

Cooperate 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.


of 118

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

12.1. Support Requirements

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

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

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

Other support requirements.

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

12.2. Pre-Existing Materials

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

12.3. Commercial Materials

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


of 118

rejection of the offeror’s Proposal, if the State, in its sole discretion, believes that such is not appropriate or desirable for the Project. Any deviation from the standard license, warranty, and other terms in Attachment Four also may result in a rejection of the offeror’s Proposal.

If the offeror proposes a Deliverable that contains Commercial Software or other Commercial Materials with terms that differ from the terms in Attachment Four for Commercial Software and Materials, then those terms must be detailed here, and any proposed separate agreement covering those items must be included in the Offeror’s Proposal. This is required even if the State will not be expected to sign the agreement. Any deviation from the standard terms in Attachment Four may result in a rejection of the offeror’s Proposal.


of 118

13. Reference Information and Additional ExhibitsThe following reference information and additional exhibits are designed to assist offerors in the formulation of an overall proposal to this RFP and are based upon the current implementation of the LMP at the State. No requirements exist in this section, but offerors, as part of their response must provide an affirmational statement to the effect that these materials were reviewed and factored in their entirety as part of their response to this RFP.

Document Contents Embedded File

DOLC - Solution Design Document v.final 20161219.PDF

Overall Solution Design (Business, Process, Functional)

Application Architecture

Data Architecture

Integration Architecture

Security Architecture

Deployment Architecture (Technical Details, Sizing Information)

CLICK ICON BELOW TO

ACCESS CONTENTS


of 118