State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 1 of 116
Supplement 1 Liquor Management System
Application Management and Operations
Table of Contents
1. Business Background and Overview ............................................................................................................................. 3 1.1. Background and Introduction ...................................................................................................................................................... 3 1.2. Organization of Work Areas ........................................................................................................................................................ 4 1.3. Service Objectives ...................................................................................................................................................................... 6 1.4. Offeror Differentiators ................................................................................................................................................................. 6 1.5. Current Environment: General Reference Information ............................................................................................................... 7
2. General System Operation, Maintenance and Development Requirements ............................................................. 10 2.1. Development and Operations Conventions and Requirements ............................................................................................... 10 2.2. State Infrastructure Obligations ................................................................................................................................................ 11 2.3. Ownership and Licensing Considerations ................................................................................................................................ 12
3. Systems Operations, Maintenance and Support Services (“Steady State Services”) ............................................. 14 3.1. Project/System Change Management Support Services ......................................................................................................... 14 3.2. State Application Help Desk Implementation and Ongoing Level 2 / 3 Help Desk Services .................................................... 16 3.3. Environment Review and Advisory Services ............................................................................................................................ 22 3.4. Problem Management Support Services .................................................................................................................................. 22 3.5. Release and Configuration Management Requirements .......................................................................................................... 23 3.6. Break/Fix Services .................................................................................................................................................................... 24 3.7. Environment Management (Production, Non-Production, QA, Projects, Demo/Train, Test) .................................................... 25 3.8. System Backup, Backup Validation and Restoration Requirements ........................................................................................ 26 3.9. System Environment and Service Architecture, Standards and Advisory Services ................................................................. 27 3.10. User Management and Administration ..................................................................................................................................... 27 3.11. Software Product Evolution and Roadmap Planning/Advisory Services .................................................................................. 27 3.12. System and Performance Testing / Validation ......................................................................................................................... 28 3.13. Program Management & Master Release Calendar ................................................................................................................. 29 3.14. Disaster Recovery Planning Support and Implementation ....................................................................................................... 29 3.15. Legal/Regulatory and Minor Change Requirements ................................................................................................................ 31 3.16. Maintaining Solution and Operations Documentation .............................................................................................................. 32 3.17. Annual Technology, Infrastructure Optimization: Planning and Updates ................................................................................. 32
4. Steady State Run Services – Service Level Agreements ........................................................................................... 34 4.1. Scope Considerations as they relate to Service Levels and Contractors Supporting of the State ........................................... 34 4.2. Service Level Specific Performance Credits............................................................................................................................. 35 4.3. Period Service Level in Full Effect and In-Progress Service Levels ......................................................................................... 36 4.4. LMP System Steady State Support Services: Service Level Requirements ............................................................................ 36
5. State Option: Field Service Technician & Technical Support Services .................................................................... 46 5.1. Remedial Maintenance and Installation Responsibilities .......................................................................................................... 46 5.2. Service Request and Response Requirements ........................................................................................................................ 46 5.3. Preventative Maintenance Requirements ................................................................................................................................. 46 5.4. Maintenance Reporting Requirements and Responsibilities .................................................................................................... 47 5.5. Preventive Maintenance and Support Plan .............................................................................................................................. 49 5.6. Telephone Support and Notification Requirements .................................................................................................................. 49 5.7. Solution Element Change Management (Hardware, Software, Devices and Other Offeror Provided Elements) .................... 50
6. Project Based Services ................................................................................................................................................. 52 6.1. Project/Enhancement/Upgrade Delivery: Full Lifecycle SDLC Deliverables and Process ....................................................... 52 6.2. Knowledge Transfer and Educational Services ........................................................................................................................ 64 6.3. Contractor System Development Environment Management Responsibilities ........................................................................ 65 6.4. Periodic Technology Refresh and Update Support Services ................................................................................................... 66
7. Identified Major Projects ............................................................................................................................................... 69 7.1. Microsoft Dynamics “Next” Upgrade ......................................................................................................................................... 69 7.2. Microsoft Azure Migration (Production and/or DR) ................................................................................................................... 74 7.3. Future Projects, Enhancements and System Evolutions .......................................................................................................... 79 7.4. Major Projects, Enhancements, Upgrades and Program Support – Service Level Agreements .............................................. 80
8. Contractor Staffing Requirements ............................................................................................................................... 94 8.1. Work Location(s) and Contractor Personnel Involvement ........................................................................................................ 94 8.2. Microsoft Dynamics and Platform Element Accreditation and Certification Requirements ...................................................... 95 8.3. Use of State Provided SharePoint® Collaboration Site, Use of State eMail Exchange® ......................................................... 96
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 2 of 116
9. Service Establishment Requirements – Transition from Current State to Managed Service ................................. 97 9.1. Overview of Scope .................................................................................................................................................................... 97 9.2. Service Establishment / Transition Management ..................................................................................................................... 97 9.3. Service Establishment / Transition Plan ................................................................................................................................... 97 9.4. Service Establishment / Transition Process ............................................................................................................................. 98 9.5. Service Establishment / Transitioning Planning and Analysis .................................................................................................. 99 9.6. Service Establishment: Service Operations Design-Build Services ......................................................................................... 99 9.7. Service Establishment - Transition Test/Acceptance. ............................................................................................................ 101 9.8. Service Establishment - Service Deployment ......................................................................................................................... 101 9.9. Service Establishment - Staffing Plan and Time Commitment ............................................................................................... 101
10. Contract Governance .................................................................................................................................................. 104 10.1. Contractor Account Representative ........................................................................................................................................ 104 10.2. State Account Representative ................................................................................................................................................ 104 10.3. Participation and Support of Service Management Steering and Oversight Committee ........................................................ 104 10.4. Regular Meetings and Conference Calls ................................................................................................................................ 105 10.5. Issue and Dispute Resolution Process ................................................................................................................................... 105 10.6. Billing and Invoicing ................................................................................................................................................................ 107 10.7. Service and Work Effort Reporting ......................................................................................................................................... 107 10.8. Back-Up Documentation ......................................................................................................................................................... 108 10.9. Correction of Errors ................................................................................................................................................................ 108
11. Contract Conclusion Requirements: Transition to Successor/State at Contract Termination or Non-Renewal ................. 110 11.1. Overview ................................................................................................................................................................................. 110 11.2. Responsibilities ....................................................................................................................................................................... 110 11.3. Standards ............................................................................................................................................................................... 112 11.4. Termination Assistance Plan .................................................................................................................................................. 112 11.5. Termination Management Team............................................................................................................................................. 113 11.6. Operational Transfer ............................................................................................................................................................... 113
12. Assumptions ................................................................................................................................................................ 114 12.1. Support Requirements ............................................................................................................................................................ 114 12.2. Pre-Existing Materials ............................................................................................................................................................. 114 12.3. Commercial Materials ............................................................................................................................................................. 114
13. Reference Information and Additional Exhibits ........................................................................................................ 116
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 3 of 116
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.
▪ (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 of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 4 of 116
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:
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 5 of 116
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 6 of 116
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;
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 7 of 116
• 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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 8 of 116
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)
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 9 of 116
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 10 of 116
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.
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 11 of 116
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 ▪ Capacity Management ▪ Batch Operations/Scheduling ▪ Storage Management ▪ Backup/Restore (Service/Device)
Data Center Facilities Management
▪ Site Maintenance and Operations ▪ Site Availability Management ▪ Routine Maintenance and Upgrades
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 12 of 116
State Infrastructure Responsibility Matrix
▪ 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 3rd 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
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 13 of 116
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 14 of 116
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;
▪ Coordinate and confirm the State approval of data conversion results;
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 15 of 116
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 16 of 116
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
support of Contractor
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 17 of 116
Help Desk Level /
Support Tier Representative Functions Responsibility
alteration to the State operational software base)
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;
▪ Resolution and recovery;
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 18 of 116
▪ 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.
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 19 of 116
▪ 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
▪ Be responsible for the resolution or closure of all calls related to products and services that are not within
the Contractor’s scope Services.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 20 of 116
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
▪ Working to correct environment defects or problems that require environment code or operational
modifications.
The State will:
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 21 of 116
▪ 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)
Help Desk Tier State LMP Application
Level 1
(Login/Password, FAQ, State Devices, Navigation etc) Issues/Questions
State Managed, Out of Contractor Scope
State 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 Scope
State experience is that 10% of all requests
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 22 of 116
Help Desk Tier State LMP Application
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.
Contractor responsibilities further include:
▪ Analyzing trends and participating in the State continuous improvement process striving to enhance its
operations and identifying continuous improvement ideas.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 23 of 116
▪ 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 3rd 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 3rd 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
Changes Modify/Enhance Applications with Simple Configuration. No Code Changes Required State
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 Contractor
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 24 of 116
Release / Configuration
Management Scope Considerations / Criterion Responsibility
consideration as to not adversely impact system functions or operations.
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
The Contractor must:
▪ 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-
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 25 of 116
▪ 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)
The Contractor must:
▪ 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.
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 26 of 116
▪ 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
software
All O/S configuration files and related
Infrastructure software Monthly 12 Months
Database All Database Weekly (weekend) 12 Months
Full Backup Copy
At 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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 27 of 116
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.
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:
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 28 of 116
▪ 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.
▪ 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).
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 29 of 116
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.
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 30 of 116
▪ 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:
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 31 of 116
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:
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 32 of 116
3.16. Maintaining Solution and Operations Documentation
The Contractor must:
▪ 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 3rd 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):
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 33 of 116
▪ 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.
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 34 of 116
4. Steady State Run Services – Service Level Agreements
The 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 3rd 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 35 of 116
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 36 of 116
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 37 of 116
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 38 of 116
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 hours
Yellow > 4 hours and <= 6 hours
Red > 6 hours
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 39 of 116
4.4.2. Incident Resolution – Mean Time to Repair (Severity 2 Issues)
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).
Formula: Mean Time to Repair
(Severity 2 Issues) =
Total elapsed time it takes to repair Severity 2 Issue
Service Requests
Total Severity 2 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 2 Issues).
Green <= 8 hours
Yellow > 8 hours and <= 12 hours
Red > 12 hours
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 40 of 116
4.4.3. Incident Resolution – Mean Time to Repair (Severity 3 Issues)
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.
Formula: Mean Time to Repair
(Severity 3 Issues) =
(Total elapsed time it takes to repair Severity 3 Issue
Service Requests)
Total Severity 3 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 3 Issues).
Green <= 5 business days
Yellow > 5 business days <=7 business days
Red > 7 business days
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 41 of 116
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
Measurement
Period: Reporting Month
Data Source: Monthly Service Report
Frequency of
Collection: Continuous, 24 hours a day as per Production Release Schedule
Service Level Measures:
Individual SL GYR State Production Release Management
Green < = 5%
Yellow >=5% - <=7%
Red > 7%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 42 of 116
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
Service Level Measures:
Individual SL GYR State
Incident Resolution - Incident Triage and
Closure and Recidivist Rate
Green >= 99.5
Yellow < 99.5 and > =99.3
Red < 99.3
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 43 of 116
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
Service Level Measures:
Individual SL GYR State
Job Schedule and Scheduled
Reporting Performance
Green <= 10%
Yellow > 10% <= 15%
Red > 15%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 44 of 116
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
Measurement
Period: Monthly
Data Sources: Production Change Report
Frequency of
Collection: Each Change to Production and Follow-On Changes to Non-Production
Service Level Measures:
Individual SL GYR State Service Quality – System Changes
Green <= 2%
Yellow > 2% <= 5%
Red > 5%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 45 of 116
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
Measurement
Period: Monthly
Data Sources: Help Desk Escalation Report
Frequency of
Collection: Monthly
Service Level Measures:
Individual SL GYR State
Help Desk Services
Responsiveness and Closure Rate
Green <= 2%
Yellow > 2% <= 5%
Red > 5%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 46 of 116
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.
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 47 of 116
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.
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”.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 48 of 116
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
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 49 of 116
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
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 50 of 116
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.
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 51 of 116
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 52 of 116
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:
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 53 of 116
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 54 of 116
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);
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 55 of 116
▪ 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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 56 of 116
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 57 of 116
• 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
The Contractor must:
▪ 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;
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 58 of 116
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 59 of 116
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:
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 60 of 116
▪ 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;
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 61 of 116
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.
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)
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 62 of 116
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.
▪ Compile and maintain solution issue lists;
▪ Conduct quality and progress reviews with appropriate the State personnel;
▪ Coordinate and confirm the State approval of solution components and verification of applicable
acceptance criteria for transition into deployment and production use; and
▪ Provide the State with reports on a weekly basis tracking the progress of Contractor’s performance of
testing work, or in the case of user acceptance testing, support of the State activities.
▪ 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).
Deliverable 8. State User Acceptance Testing Completion
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 63 of 116
6.1.8. Pre-Production / Production Deployment Phase
The Contractor is responsible for working with the State and its 3rd 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;
▪ Compile and maintain solution issue lists;
▪ 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 64 of 116
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 65 of 116
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
High level descriptions of the instances are as follows:
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 66 of 116
▪ 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).
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 67 of 116
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.
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 68 of 116
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 69 of 116
7. Identified Major Projects
Important 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
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 70 of 116
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
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 71 of 116
▪ 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)
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 72 of 116
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 73 of 116
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 74 of 116
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 75 of 116
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
Disaster
Recovery
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 76 of 116
▪ 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.
Develop detailed test plans for migration validation and support of cut-over decision
making by the State.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 77 of 116
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
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 78 of 116
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
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 79 of 116
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,
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 80 of 116
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.
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 81 of 116
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.
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 Hours Required
Response Resolution
1 Defect Resolution – Severity 1 Items 7x24 Every 4 hours until resolution <= 24 hours
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 82 of 116
No Service Level Agreement Support Hours Required
Response Resolution
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 -
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 83 of 116
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 hours
Yellow >24 hours and <= 48 hours
Red >48 hours
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 84 of 116
7.4.5. Defect Resolution – Mean Time to Repair/Resolve (Severity 2 Items)
Specification: Defect Resolution – Mean Time to Repair/Resolve (Severity 2 Items)
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)
=
=
(Total elapsed time it takes to repair Severity 2 Defect Service
Requests)
(Total Severity 2 Defect Service Requests)
Measurement
Period: Accounting Month
Data Source: Monthly Project Report
Frequency of
Collection: Per Incident
Service Level Measures
Individual SL
State Mean Time to Repair (Severity 2 Defects).
Green <=72 hours
Yellow >72 hours and <= 90 hours
Red >90 hours
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 85 of 116
7.4.6. Defect Resolution – Mean Time to Repair/Resolve (Severity 3 Items)
Specification: Defect Resolution – Mean Time to Repair/Resolve (Severity 3 Items)
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)
=
=
(Total elapsed time it takes to repair Severity 3 Defect Service
Requests)
(Total Severity 3 Defect Service Requests)
Measurement
Period: Accounting Month
Data Source: Monthly Project Report
Frequency of
Collection: Per Incident
Service Level Measures
Individual SL
State Mean Time to Repair (Severity 3 Defects).
Green <= 7 calendar days
Yellow > 7 calendar days and <= 10 calendar days
Red > 10 calendar days
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 86 of 116
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
Measurement
Period: Accounting Month
Data Source: Monthly Project Report
Frequency of
Collection: At end of System Test
Service Level Measures
Individual SL
State System Test Execution Exit Quality Rate
Green >= 90%
Yellow >= 85%, <90%
Red < 85%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 87 of 116
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
Measurement
Period: Accounting Month
Data Source: Monthly Project Report
Frequency of
Collection: Per Incident
Service Level Measures
Individual SL
State
Blocking Issue Identification and
Removal
Green <= 10%
Yellow >10%, <= 12%
Red <= 15%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 88 of 116
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
Measurement
Period: Accounting Month
Data Source: Monthly Project Report
Frequency of
Collection: At end of UAT phase for each release to Production
Service Level Measures
Individual SL
State Issue Find/Fix Rate
Green <= 10%
Yellow >10%, <= 12%
Red <= 15%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 89 of 116
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
Service Level Measures
Individual SL
State % Compliance Milestone Dates
Green > 90%
Yellow > 85%, <=90%
Red <= 85%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 90 of 116
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 Period
X 100
Measurement
Period: Monthly, During Project
Data Source: Weekly Project Report
Frequency of
Collection: Weekly
Service Level Measures
Individual SL
State % Deliverable Acceptance
Green > 85%
Yellow > 80%, <=85%
Red <= 80%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 91 of 116
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
Measurement
Period: Monthly, During Project
Data Source: Weekly Project Report
Frequency of
Collection: Weekly
Service Level Measures
Individual SL
State % SDLC Compliance
Green > 95%
Yellow > 90%, <=95%
Red <= 90%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 92 of 116
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 Release
X 100
Measurement
Period: Monthly, During Project
Data Source: Weekly Project Report
Frequency of
Collection: Weekly
Service Level Measures
Individual SL
State
Issues Detected and Resolved in
Production
Green <= 2%
Yellow > 2%, <=3%
Red > 3%
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 93 of 116
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 94 of 116
8. Contractor Staffing Requirements
As 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%.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 95 of 116
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 Retail
MB6-705: Microsoft Dynamics AX 2012 R3 CU8 Installation and
Configuration
MB6-890: Microsoft Dynamics AX Development Introduction
MCSA/E – SQL 2014 (or Higher) Database Administration
MCSA/E – Web Applications
MCSA/E – Windows Server 2012 (or Higher)
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 96 of 116
MB6-892: Microsoft Dynamics AX Distribution and Trade
MB6-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,
vulnerabilities, risks and project matters or may be considered advantageous to gaining unauthorized access to
State systems, infrastructure or data.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 97 of 116
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.
The Contractor must:
▪ 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:
An inventory and description of the IT operations being migrated;
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 98 of 116
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 discrete activities tasks as part of the transition planning process. The State will provide availability of
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 99 of 116
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
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,
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 100 of 116
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.
▪ Coordinate with State infrastructure management experts to implement required technology environment
changes as mutually agreed.
▪ Conduct Service build progress reviews with appropriate State personnel.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 101 of 116
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.
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 102 of 116
▪ 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 11
Phase Startup / Analyze
Design Phase Build Phase Test Phase Deployment Operate
Project Management
State 3 3 3 3 3 3 3 3 3 3 3
Contractor 2 2 2 2 2 2 2 2 2 2 2
Functional FTEs
State 4 4 4 4 4 4 4 4 4 4 4
Contractor 8 8 8 8 8 8 8 8 8 8 8
Technical FTEs
State Infrastructure 2 2 2 2 2 2 2 2 2 2 2
State Security 1 1 1 1 1 1 1 1 1 1 1
Contractor 6 6 6 6 6 6 6 6 6 6 6
Business / Agency FTEs
State 4 4 4 4 4 4 4 4 4 4 4
Contractor 2 2 2 2 2 2 2 2 2 2 2
Summary Total
State 14 14 14 14 14 14 14 14 14 14 14
Contractor 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.
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 103 of 116
▪ 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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 104 of 116
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 105 of 116
▪ 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
dispute. The Services Oversight Council will address the dispute in an effort to resolve such dispute
without the necessity of any formal proceeding.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 106 of 116
▪ 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.
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 107 of 116
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.
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
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 108 of 116
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;
▪ All open or recurring issues between the parties inclusive of incident, problem and change performance,
defects and other items that either party deems unsatisfactory;
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 109 of 116
▪ 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).
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 110 of 116
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 111 of 116
▪ 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 3rd Party to prepare an informed
option analysis for such services, and for the State or a 3rd 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 3rd 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 112 of 116
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 3rd 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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 113 of 116
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 114 of 116
12. Assumptions
The 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
rejection of the offeror’s Proposal, if the State, in its sole discretion, believes that such is not appropriate or
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 115 of 116
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.
State of Ohio: Department of Commerce Supplement 1 - Liquor Management System - Managed Services Page 116 of 116
13. Reference Information and Additional Exhibits
The 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