view Enterprise Mdm Supplement 1 - Ohio - State of Ohio ... · Web viewAfter award of Contract and commencement of work by the Contractor, the Enterprise MDM Project will be in a

Supplement 1

Enterprise Master Data Management (MDM) Requirements, System Development Methodology and Staffing Requirements

State of Ohio Department of Administrative Services, Office of Information TechnologySupplement 1-Enterprise MDM Requirements, System Development Methodology and Staffing Requirements RFP 0A1213 Page 1

Table of Contents1.0 Enterprise Master Data Management: Background and Overview 4

1.1 General Scope 41.2 Discovery Period 6

2.0 General Project Requirements 62.1 Data Management Strategy 62.1.1 Data Governance & Stewardship 62.1.2 Data Quality Management 62.1.3 Metadata Management 72.1.4 Key Deliverables 72.2 Enterprise MDM Solution Architecture 72.2.1 Key Deliverables 82.3 Ohio Benefits Expansion and Hardware Upgrade 82.3.1 Key Deliverables: 92.4 Enterprise MDM Service Integration with EDW 102.4.1 Key Deliverables: 102.5 JFS Enterprise MDM Initiative 112.5.1 Key Deliverables: 112.6 Medicaid Provider Management 122.6.1 Key Deliverables: 122.7 Identity Management Integration 132.8 Development and Testing Environment Support 132.9 Maintenance and Operations 132.10 Data Quality Execution 132.11 Unanticipated Project Services 14

3.0 Solutions Requirements: Business, Data and Non-Functional Requirements 143.1 Overview of State Systems Referenced in this Supplement 143.2 Additional State Data Stores 143.3 Solution Sizing Requirements 153.4 Organization of Requirements 153.5 Business Requirements 173.6 Data Requirements: “Individual” Domain 293.7 Data Element Requirements: “Business” Domain 333.8 Non-Functional Requirements 353.9 RFP Assumptions 44

4.0 State Project Delivery, Management, Methodology and Approach Requirements 444.1 Project Management and Coordination Services 464.2 State Project Governance Considerations 474.3 Create and Maintain Project Plan 474.4 Project Financial Management 494.5 Project Review Check Point 514.6 Meeting Attendance and Reporting Requirements 514.7 Utilize OIT’s Document Sharing/Collaboration Capability 524.8 Production/Version Control and Release Management 534.9 Maintaining Solution and Operations Documentation 544.10 Project Delivery, Role and Responsibility Requirements 544.11 System/Environment Administration Support of the Project 544.12 Establish and Manage a Program Management & Master Release Calendar 554.13 Cooperation with State and State Contractors 554.14 Requirements Confirmation and Analysis (for each release) 554.15 Current Environment Assessment 554.16 Data Governance and Stewardship 564.16.1 Agency Data Quality Improvement Plan 564.17 Analyze Phase Requirements (for each planned release) 564.18 Design Phase Requirements (for each planned release) 574.19 Build Phase Requirements (for each planned release) 584.20 Test Phase Requirements (for each planned release) 584.20.1 Project Incident Management 604.20.2 Project Defect Management 604.21 Deploy Phase Requirements (for each planned release) 614.22 Organization Change Management 62


4.23 Knowledge Transfer and Production Handoff (for each planned release) 634.24 Project Completion Activities, Final Documentation and Post Implementation Support Obligations 644.25 Future Project Services Pricing Response and Rate Card 64

5.0 Schedule of Deliverables and Work Products 655.1 Delivery and Deliverable Standards 655.2 Schedule of Deliverables and Work Products 65

6.0 State Staffing Requirements 786.1 Contract Staffing and Key Activities 806.2 Staffing Plan and Time Commitment 816.3 Background Checks 82

7.0 Assumptions 837.1 Support Requirements 837.2 Pre-Existing Materials 837.3 Commercial Materials 83

8.0 Informatica Platform Environments 848.1 Informatica Platform Environment Implementation and Support During Development 84

9.0 Appendix A: Project Development Methodology Deliverables by Release 85


1.0 Enterprise Master Data Management: Background and Overview

The State is currently completing work on a Master Data Management (MDM) implementation which supports a cross-agency Integrated Eligibility solution. This MDM implementation when completed will contain two Master Data domains referred to as the Master Client Index (MCI) and Master Provider Index (MPI). This MDM implementation is built using the Informatica Multi-Domain MDM platform, and is used to prevent data from being duplicated at the point of entry within the Integrated Eligibility system.

The purpose of this project is to expand the current MDM implementation with data from additional agencies and to enhance or add key MDM business capabilities. This expansion will advance the State’s ability to share and use Master Data within and across agencies, while accounting for Federal Regulations, Ohio Revised Code, and inter-agency data use agreements which govern the ability to do so. The scope of the Enterprise MDM RFP will involve incorporating data from a limited set of systems from three (3) State Agencies: Ohio Department of Medicaid (ODM), Ohio Department of Job and Family Services (JFS) and Ohio Department of Administrative Services (DAS). The scope will allow the business capabilities to expand beyond the current focus on duplicate detection to include:

Facilitation of cross-agency integration via a common registry of system identifiers (IDs)

Improved Data Quality at point of entry via integrated data quality rules

Enhanced analytics through use of a harmonized golden record

1.1 General Scope

Provide a functional (process and data quality) and technical assessment (design) of the current MDM implementation, documenting lessons learned and recommendations for the future state architecture

Design and gain approval for an Enterprise MDM architecture which supports data maintenance, data integration and analytics use cases for ODM, JFS and DAS as defined in Section 2.0

Ensure the Enterprise MDM solution will be able to support three (3) Master Data Domains: Individual, Business, and Employee, and a common set of Master Reference Data. Only Individual, Business and Master Reference Data are in scope. The domains are defined as follows:

Individual: An Individual who is interacting for themselves or on the behalf of another Individual to engage with or receive services from the State. An Individual has various internal names including citizen, resident, client, recipient, beneficiary, individual tax payer, claimant, seeker, providers, etc.

Business: A business is an individual or organization who is engaged in providing products or services to or on behalf of the State. A Business has various internal names including licensed/certified providers, local education districts, hospitals, day care centers, community homes, payers, pharmacies, laboratories, vendor, etc.

Employee: Any individual who is fulfilling the role of a known State agency employee, contingency worker, contract worker, staff, Contractor, etc.

Master Reference Data: Master Reference Data is any look-up data, look-up codes or any other type of data that is used exclusively for categorizing data within one of the primary Data Domains


Ensure the architecture is flexible to expand scope over time with respect to modifying the number of hubs, agencies, source/target systems, domains, tables, attributes, rules, algorithms, etc.

Ensure the architecture complies with all Federal, State and inter-agency guidelines with respect to the use and sharing of data between ODM, JFS and DAS, and can be expanded to additional agencies as business needs require

Design, develop and implement a Data Governance and Stewardship strategy, which accounts ensuring timely decisions are made and that data is actively managed and monitored to ensure initial and on-going data quality

Design, develop and implement a Data Quality Management strategy which allows for the proactive definition, documentation and education of Master Data quality standards and the active review of data to ensure adherence to defined standards

Design, develop and implement a Metadata Management strategy, which will result in standardized processes and tools for obtaining, verifying, storing and distributing business/technical metadata relevant to the Enterprise MDM implementation utilizing Informatica’s Business Glossary and Metadata Manager

Lead the data remediation efforts to ensure that the Enterprise MDM solution is loaded with high quality Master Data

Work with each Agency to re-assess, refine and validate functional, data and non-functional requirements to ensure a complete and implementable set of requirements for the releases identified in Section 2.3, 2.4, 2.5 and 2.6

Design, build, test, implement and provide warranty support for the releases identified in Sections 2.3 and 2.4

Complete the design work, and create implementation plans for the releases identified in Sections 2.5 and 2.6

Specify and implement Informatica Platform environments to support development and testing activities for the releases identified in Sections 2.3, 2.4, 2.5 and 2.6 consistent with environment requirements defined in Sections 2.8 and 8.0

Provide industry best practices for integrating an Identity Management solution with a Master Data Management solution as defined in Section 2.7

Define and document a post-implementation Maintenance and Operations (e.g., “Run”) strategy for the Enterprise MDM environment

Assume ownership for Maintenance and Operations (M&O) for releases covered in Section 2.3 and 2.4 once the respective warranty periods have completed

Overview of anticipated releases:

Refer to Document Section #:

Release Domains in Scope

Agencies in Scope

Source System Consuming System

Anticipated Project Release Date

2.3 Ohio Benefits expansion and hardware upgrade

Individual Business

DAS Medicaid JFS

Ohio Benefits Master Client

Index

EDW Ohio Benefits MMIS

May/Jun 2018

2.4 Enterprise MDM Service integration with EDW

Individual Business

Medicaid Enterprise MDM Enterprise Data Warehouse

Sep 2018

2.5 JFS Enterprise MDM Initiative

Individual JFS OJI OWCMS Ohio Benefits + 1 TBD

OJI OWCMS Ohio Benefits

Multi-PhaseApril 2018TBD

2.6 Medicaid Provider Business Medicaid MMIS EDW No earlier than


Refer to Document Section #:

Release Domains in Scope

Agencies in Scope

Source System Consuming System

Anticipated Project Release Date

Management DAS – OAKS (Finance)

OAKS OAKS Dec 2018

2.7 Identity Management (IDM) Integration

Future DAS - DX IDM N/A Future

1.2 Discovery PeriodAfter award of Contract and commencement of work by the Contractor, the Enterprise MDM Project will be in a Discovery Period. The discovery period is anticipated to have a duration of approximately three (3) months and is comprised of the Enterprise MDM Solution Architecture, Data Management Strategy, and Ohio Benefits Expansion and Hardware Upgrade work that will occur during this timeframe. Any State-approved refinements to the Project or Work required due to the discovery period, may be cause for a limited fee adjustment. During the discovery period, a Go/No-Go decision will be made by the State. If the State decides not to go forward with the Work described in this Supplement, cancels this RFP for any reason, or contracts for the Work through some other process or through another RFP, the State will be liable to the Contractor for those deliverables completed and approved by the State during the discovery period.

2.0 General Project Requirements

2.1 Data Management Strategy

2.1.1 Data Governance & Stewardship The State has implemented Data Governance practices to drive business-centric decision-making within agencies. As the State expands the use of the Master Data Management service across agencies, it recognizes that its Data Governance practices must do the same. The State is asking for the Offeror to evaluate current Data Governance practices, and to propose and implement a Data Governance Strategy and Framework that recognizes the unique decision-making needs at the State and Agency levels

The Offeror will be expected to:

Define a Data Governance Strategy and Framework to meet State and Agency Level needs

Define and Document key aspects of the framework including policies, procedures, roles & responsibilities, key performance indicators, etc.

Mentor individuals assigned to Data Governance roles

2.1.2 Data Quality ManagementThe State understands the importance of ensuring quality data is loaded into the Enterprise MDM, and the need to continually and proactively monitor the data over time to ensure Data Quality persists. The Offeror will be expected to develop a Data Quality Strategy and Approach which will, at a minimum, encompass the following:

Processes to define, approve data quality standards, match rules, merge rules, unmerge rules, etc.

Formalized approaches to:


Profile and analyze data Identify, document and remediate data quality issues Identify missing data and establish enrichment plans Monitor data quality over time Develop reusable data quality rules to automate data standardization and cleansing

Training materials to train Data Governance and Project team members on Data Quality Management

2.1.3 Metadata Management The State understands that as it continues to drive stronger Data Management practices, the importance of managing its Business and Technical metadata will increase. Therefore, the Offeror is expected to develop an approach to creating, managing and making available Metadata related to the Enterprise MDM implementation. The Offeror will be expected to:

Develop a Metadata Management Strategy and Approach to manage and monitor the metadata

Install and Configure Informatica Business Glossary and Metadata Manager in accordance with the defined process and metadata attribute requirements

Train Data Stewards and project team members on the processes and tools adopted

Import relevant existing Metadata into the tools

Support the Business Glossary and Metadata Manager environments during the project phases

Define and implement processes to maintain Business Glossary and Metadata Manager environments on an ongoing basis.

2.1.4 Key Deliverables Data Governance Strategy and Framework

Metadata Management Strategy and Approach

Data Quality Management Strategy and Approach

Organizational Change Strategy and Plan

Organization Change Job Aids and Training Materials

Training materials (guides, job aids and/or play or run books) for Business Glossary and Metadata Manager

Refer to Sections 4 and 5 as well as Appendix A of this supplement for a complete discussion of methodology, deliverables and work products

2.2 Enterprise MDM Solution Architecture The long-term architectural direction with respect to the architecture model (single or multiple hubs) and the implementation style (Consolidation, Co-existence, Transaction, etc.), which must be implemented, are not defined. The Offeror is being asked to assess the defined functional requirements, data requirements, non-functional requirements, current state architecture, relevant Federal and State laws pertaining to sharing data


across agencies (please refer to Supplement 2), and to propose an Enterprise MDM solution architecture and implementation style.

The proposed Enterprise MDM solution architecture must make use of Informatica’s Multi-Domain MDM solution. The State has procured an enterprise license for Informatica Multi-Domain MDM, which has sufficient licensing to support up to nine (9) hub instances, each containing up to four (4) data domains with an unlimited number of consolidated records. Additionally, the State has no limitations on the number of named users of Informatica Data Director (IDD).

The State has the following additional Informatica technologies, which must be considered as the overall architecture is designed

Informatica PowerCenter

Informatica Data Quality

Informatica Business Glossary

Informatica Metadata Manager

2.2.1 Key Deliverables Current Environment Architectural Assessment

Proposed Solution Architecture


2.3 Ohio Benefits Expansion and Hardware Upgrade The Ohio Department of Administrative Services (DAS) in coordination with the Ohio Department of Medicaid (ODM) and the Ohio Department of Job and Family Services (JFS) have jointly implemented an Integrated Eligibility solution, Ohio Benefits (O.B.). To provide enhanced capabilities for managing and searching for Individual (Client) and Business (Provider) Master Data, O.B. was integrated with a lightweight MDM implementation. The existing MDM solution provides a Master Data repository and probabilistic search capabilities to identify and prevent duplicate records from being introduced into the Ohio Benefits solution. To continue to improve data quality, the goal of this project is to transition from a lightweight MDM implementation to a more robust solution and to transition to a new hardware infrastructure, which will be provided by the state. As part of this initiative, the Offeror will be expected to:

Partner with the DAS-OIT team to define HW specifications

Install, configure and support Informatica Multi-Domain MDM and other required platform services during the project

Assess and enhance, as appropriate, search capabilities used to identify potential duplicates early in the Master Data Management process

Partner with the assigned Data Steward to create new workflows to:

Standardize, Cleanse and Enrich source system data as required to meet eEnterprise MDM data standards


Identify duplicate records and, when necessary, manually resolve them into a single global record, with a unique global identifier

Monitor Enterprise MDM Process and Master Data quality key performance indicators (KPI’s) to ensure the efficiency and effectiveness of the solution

Implement automated data integration between the Enterprise MDM service, O.B. and MMIS to eliminate manual processes currently required in each source system to propagate updates resulting from changes to Master Data (e.g., attributes, merge, unmerge, etc.)

Refer to Section 3 of this supplement for a complete list of business, data and non-functional requirements

2.3.1 Key Deliverables: Project Charter, Plan, and Kick-Off Package

Data Cleansing Approach and Tools

Requirements Definition

Solution Architecture

Data Quality Remediation Plan

Implementation & Deployment Strategy

Capacity Plan

Functional Design Document(s)

Technical Design Document(s)

Security Design

Technology Environments for Development and Test

Data Conversion/Migration Plan

Test Strategy

Data Quality Scorecard

Solution Component Code, Objects & Configuration

Test Scripts & Cases

Deployment & Stabilization Plan

System Test Results Report

Performance Test Results Report

User Acceptance Test Results Report

Operational Readiness Test Results Report

System Turnover



2.4 Enterprise MDM Service Integration with EDW The Ohio Department of Administrative Services (DAS) is establishing an Enterprise Data Warehouse (EDW) to provide cross-agency analytic capabilities. To facilitate the integration of data from multiple source systems, the Enterprise MDM system will become the EDW’s source of truth for Individual and Business Master Data. The outcome of the EDW Integration scope will be an enterprise methodology and initial implementation for providing the EDW with high quality Master Data. The methodology and implementation concepts must be reusable and scalable, to support the EDW as its scope expands and begins to incorporate data from additional agency solutions. As part of this initiative, the Offeror will be expected to:

Partner with the DAS EDW team to develop a transition plan to use Enterprise MDM service as the source of their master data (i.e., Individual and Business)

Convert EDW sourcing Individual and Business Master Data from MMIS to the enhanced Enterprise MDM service for Individual (Recipient) and Business (Provider) conformed dimension management.

Develop integration services which provide batch and (near) real-time look-up of the unique global identifier








Updated Capacity Plan



Security Design


Test Strategy

Data Quality Scorecard

Solution Component Code, Objects & Configuration

Test Scripts & Cases

Deployment & Stabilization Plan

System Test Results Report

Performance Test Results Report

User Acceptance Test Results ReportState of Ohio Department of Administrative Services, Office of Information TechnologySupplement 1-Enterprise MDM Requirements, System Development Methodology and Staffing Requirements RFP 0A1213 Page 10

Operational Readiness Test Results Report

System Turnover


2.5 JFS Enterprise MDM Initiative The Ohio Department of Job and Family Services (JFS) provides services to Individuals (citizens and residents of Ohio) through its various offices. Each office utilizes their own independent solutions to manage unique master lists of the Individuals for whom they provide services. JFS’s goal is to improve the management of these master lists by utilizing the Enterprise MDM service. The two primary benefits from this effort will be to minimize duplicate effort by reutilizing the data collected by peer offices and obtain a single registry of system ID’s across systems, in order to improve their ability to share information. As part of this initiative, the Offeror will be expected to expand the Enterprise MDM service to:

Support the authoring capabilities within Ohio Benefits, OJI and OWCMS solutions to meet JFS needs

Act as the single repository storing cross references of system identifiers (IDs) for JFS solutions and other State Agency solutions which share data with JFS

Support Data Steward efforts via workflows to:

Standardize, Cleanse and Enrich source system data as required to identify matching records Identify matching records and develop a registry comprised of a unique global identifier and the

respective local system identifiers (IDs) Monitor Enterprise MDM Process and Master Data quality key performance indicators (KPI’s) to ensure

the efficiency and effectiveness of the solution

Provide multiple pathways (push or pull) to access and utilize the cross reference whether real-time via web services or obtaining batch updates which can be stored locally in each respective system

Support initial data conversions and on-going data integrations of transactional data, which require look-up of the unique global identifier via batch or (near) real-time services









Functional Design Document(s) State of Ohio Department of Administrative Services, Office of Information TechnologySupplement 1-Enterprise MDM Requirements, System Development Methodology and Staffing Requirements RFP 0A1213 Page 11


Security Design


Test Strategy


2.6 Medicaid Provider Management

The Ohio Department of Medicaid is replacing its integrated Medicaid Management Information System (MMIS), with a modern, modularized implementation. The new implementation will include a module, Provider Management, to manage Business Master Data (e.g., Provider) and to integrate it across each additional MMIS module, as well as other State solutions, such as Ohio Administrative Knowledge System (OAKS). The Offeror will be expected to expand the existing MDM architecture so that it augments and supports the following capabilities provided by the Provider Management module:

Assess and enhance the search capabilities to identify potential duplicates early in the Master Data Management process

Support Data Steward efforts via workflows to:

Standardize, Cleanse and Enrich source system data as required to meet enterprise data standards Identify duplicate records and resolve them into a single global record, with a unique global identifier, as

required Monitor Enterprise MDM Process and Master Data quality key performance indicators (KPI’s) to ensure

the efficiency and effectiveness of the solution

Synchronizing changes to the Business (Provider) Master to and from other MMIS modules and other agency solutions (e.g. OAKS)












Security Design


Test Strategy


2.7 Identity Management IntegrationThe State is implementing an enterprise Identity Management (IDM) solution, and is evaluating opportunities to integrate the IDM solution with the Enterprise MDM service in order to create an enterprise view of identities and accounts across the various State solutions. The Offeror is being asked to provide an industry assessment of how leading organizations integrate these two solutions for this purpose. The Offeror is also being asked to provide examples of actual implementation experience where this integration has been performed, if available.

2.8 Development and Testing Environment SupportThe State is looking for a partner who will implement and support the development and testing environments required for the development efforts discussed in this Supplement. Infrastructure requirements for these environments are described in Section 8. The Contractor will coordinate with State OIT to procure or provision each environment. Once the infrastructure components for each environment are ready, the Contractor will be responsible for installing and configuring the Informatica platform. Additionally, the Contractor is being asked to provide technical support for these environments throughout the design, development, testing and deployment phases of each release described in this Supplement. The technical support team for these environments must include an Informatica Administrator.

2.9 Maintenance and OperationsThe State is looking for a partner who will support the Enterprise MDM platform and application components commencing with transition management activities that occur during UAT and continuing through deploying the release to the production environment and completing system turnover and knowledge management activities with the application development team. The State requests a five-year maintenance and operations contract with the Contractor with the ability to extend the contract twice for a two-year period. Please refer to Supplement 3, which outlines the State and Contractor expectations for this effort.

2.10 Data Quality Execution The State is anticipating that there will be manual efforts to review and cleanse data, above and beyond what State resources will be able to support, in order to align data with defined Enterprise MDM data quality standards. The State is looking to understand how the Offeror will be able to assist in staffing, training and managing these temporary staffing resources on behalf of the Data Steward(s). Additionally, in order to provide funding for data cleansing work required for the first two releases as defined in the RFP, the State requests that the Offeror provide a pricing for 2,000 hours of Data Cleansing Services as a separate line item as a part of the Offeror’s


response to the RFP. The estimate for these services should be calculated using a blended rate for data cleansing resources.

2.11 Unanticipated Project ServicesIn order to account for work that is identified beyond the scope documented within this RFP (i.e., unanticipated project services), the State requests that the Offeror provide a pricing for 10,000 hours of Unanticipated Project Services line item. This pool of hours will not be included as part of the Offeror’s fixed-not-to-exceed cost, but will be used to fund unplanned work and enhancements that are beyond what the Offeror has agreed to in their RFP response. The State also requests that the Offeror provide the resource/team structure planned to be utilized when performing unanticipated project service work. The estimate for these services should be calculated using the current blended rate for Unanticipated Project Services. Please refer to section 4.25 of this supplement for specifics on the rate card and blended rates for future and unanticipated project work.

Unanticipated Project Services, excludes those services for manual data cleansing identified in Section 2.9 and for Maintenance & Operations services as identified in Supplement 3. Unanticipated Project Services are not intended to cover changes in project scope for either the project overall or a specific release.

3.0 Solutions Requirements: Business, Data and Non-Functional Requirements

3.1 Overview of State Systems Referenced in this SupplementThe State has analyzed the candidate source systems for the projects, and has provided in this section an overview of the agency ownership and general sizing.

System NameAgency or Department Ownership

Contains “Individual” Master Data

IndividualRowCount

Contains “Business” Master Data

Business Row Count

MMIS ODM Yes 9,000,000 Yes 335,000Ohio Benefits DAS Yes 5,000,000 No N/AIdentity Management (IDM) DAS Yes Future Yes FutureOhio Business Gateway DAS – TAX No N/A Yes 826,236 (Future)OAKS DAS - Finance TBA To be Assessed Yes To be AssessedOJI JFS Yes 3,400,000 Yes N/AOWCMS JFS Yes 2,800,000 Yes N/AMaster Provider Index (MPI) DAS No N/A Yes In-DevelopmentMaster Client Index (MCI) DAS Yes 10,000,000 No N/A

3.2 Additional State Data StoresThe Offeror must specify how the solution will be designed and implemented to enable the State to add additional data tables, data elements, source data and agency systems data. As part of this requirement, the Contractor will produce a Logical as well as a Physical Data model for the Enterprise MDM.


3.3 Solution Sizing Requirements The Contractor must analyze the capacity requirements (compute and storage) of the systems. The Contractor will design and implement or otherwise provide tools to the State for archive and purge of data no longer required by the System to State-provided backup devices. (e.g., “backup and archive all data that is older than 5 years” or “backup and archive all load files from 2014”).

3.4 Organization of RequirementsThe State has organized its requirements in this Supplement. The below is a general organization of the State’s requirements.

Area Description / Contents

Bus

ines

s R

equi

rem

ents

This section lists the general set of business capabilities that are required for the holistic Enterprise MDM implementation. Each requirement in this section must be evaluated for its applicability for each of the identified projects.

The following is a description of each column in the table:

REQ ID: Provides the unique Id to be used for traceability during implementationRequirements Description by Category: Provides the statements of what is expected from the BI solutionRequirement Status: The current lifecycle status for the requirement

Dat

a El

emen

t Req

uire

men

ts -

Indi

vidu

al

This section lists the data elements proposed to be stored in the Enterprise MDM solution for stated and future requirements for the Individual.


Data REQ ID: Provides the unique Id to be used for traceability during implementationData Element Name: Provides the business term for the Data ElementsDescription: Provides the description of the data elementStatus: Classifies the status from a data governance lifecycle perspective Business Data Type: Classifies the data in general termsSource System: Lists the source system(s) where the data element has been identified to existReference Data Candidate: Identifies attributes which should be constrained by a list of valuesMultiple Values Permissible: Identifies if the Data Element may be present multiple times for a “unique” Master Data RecordField is Candidate for use in Matching: Identifies attributes which have been historically used to assist in data matching

Dat

a El

emen

t Req

uire

men

ts -

Bus

ines

s

This section lists the data elements proposed to be stored in the Enterprise MDM solution for stated and future requirements for the Business.


Data REQ ID: Provides the unique Id to be used for traceability during implementationData Element Name: Provides the business term for the Data ElementsDescription: Provides the description of the data elementStatus: Classifies the status from a data governance lifecycle perspective Business Data Type: Classifies the data in general termsSource System: Lists the source system(s) where the data element has been identified to existReference Data Candidate: Identifies attributes which should be constrained by a list of valuesMultiple Values Permissible: Identifies if the Data Element may be present multiple times for a “unique” Master Data RecordField is Candidate for use in Matching: Identifies attributes which have been historically used to assist in data matching


Area Description / ContentsN

on-fu

nctio

nal

requ

irem

ents

This section lists the non-functional requirements as it pertains to user access and security for the BI solution.


REQ ID: Provides the unique Id to be used for traceability during implementationNon-Functional Description by Category: Provides the statements of what is expected from the BI solutionStatus: The current lifecycle status for the non-functional requirement

RFP

A

ssum

ptio

ns

This section lists statements that are expected to be true for the requirements to be fulfilled.


Assumption ID: Provides the unique Id to be used for traceability Assumption Description: Provides the description of the assumption


3.5 Business Requirements Note: For section 3.5, Offerors can address the Business Requirements at the end of each section. Offerors do not have to address each Business Requirement individually.

REQ ID Requirement Description by Category Requirement Status

BR-DPA Data Profiling & Analysis

BR-DPA.001 The Contractor shall configure and implement Informatica Data Quality (IDQ) to allow the Data Steward (or delegate) to run periodic or on demand field level data profiling on source, target and Enterprise MDM data.

Proposed

BR-DPA-002 The Contractor shall provide the ability for the Data Steward (or delegate) to draft Data Quality rules to address data quality issues, in the IDQ and implement them.

Proposed

BR-DPA-003 The Contractor shall enable Data Stewards (or delegate) to develop Data Quality scorecard(s) and/or reports, which provide a real-time view of current data quality (Completeness, Uniqueness, Value distribution, Range, Pattern, Matches, De-duplication, Attribute data quality, Process efficiency, etc.) in Enterprise MDM.

Proposed

BR-DPA-004 The Contractor shall enable Data Stewards (or delegate) to develop historical Data Quality scorecard(s) and/or reports for a historical view and trend analysis in Enterprise MDM.

Proposed

Offeror Response

BR-PRP MDM Pre-processing

BR-PRP-001 The Contractor shall configure and implement MDM System to parse all in-bound data from source systems into Enterprise MDM to adhere to agreed upon canonical model(s).

Proposed

BR-PRP-002 The Contractor shall configure and implement MDM System to enforce minimum data requirements in order to accept any inbound data into Enterprise MDM.

Proposed

BR-PRP-003 The Contractor shall configure and implement MDM System to accept any inbound data that meets the Enterprise MDM minimum data requirements.

Proposed

BR-PRP-004 The Contractor shall configure and implement MDM System to reject any inbound data that does not meet the Enterprise MDM minimum data requirements.

Proposed

BR-PRP-005 The Contractor shall configure and implement MDM System to maintain a log of all the rejected records in an accessible repository for the Data Steward (or delegate) to review.

Proposed

BR-PRP-006 The Contractor shall configure and implement MDM System for the Data Steward to prioritize and manage remediation of rejected records.

Proposed

BR-PRP-007 The Contractor shall configure and implement MDM System for the Data Steward to delegate the review and remediation of rejected records.

Proposed

BR-PRP-008 The Contractor shall configure and implement MDM System to monitor and manage pre-processing issues until resolved through standard dashboard(s) and/or reports for the Data Stewards (or delegates).

Proposed

BR-PRP-009 The Contractor shall configure and implement MDM System to provide the Data Stewards (or delegates) the ability to create custom dashboards and/or reports for pre-processing issues.

Proposed

Offeror Response

BR-DSC MDM Data Standardization, Cleansing and Enrichment BR-DSC-001 The Contractor shall configure and implement MDM System to enforce consistent, industry

standard and re-usable set of Data Quality rules on records/fields loaded into Enterprise MDMProposed



BR-DSC-002 The Contractor shall configure and implement MDM System to standardize, cleanse and enrich all Source system data (refer to the initial list of data in the Data Requirements document) loaded into Enterprise MDM enforcing the to-be established Data Quality rules and standards.

Proposed

BR-DSC-003 The Contractor shall configure and implement MDM System to maintain both the original source system data (without any changes) and standardized/cleansed/enriched data in Enterprise MDM.

Proposed

BR-DSC-004 The Contractor shall configure and implement MDM System to standardize the Source system addresses to US Postal Standards or respective International Postal Standards. For example:> Validation/Cleansing of address information shall preserve all salient data during manual and systematic data cleansing (e.g., Apartment No., Lot No.) > Zip+4 shall be added to each US Postal Address> Each address shall be geo-located

Proposed

BR-DSC-005 The Contractor shall configure and implement MDM System to standardize the Source system phone numbers to the North American Numbering Plan (NANP) and other to be established national/international standards.

Proposed

BR-DSC-006 The Contractor shall configure and implement MDM System to enforce the Data Quality Rules (to be defined) across all Enterprise MDM data entry points.

Proposed

BR-DSC-007 The Contractor shall configure and implement MDM System with ability to enrich/enhance/improve MDM data quality by loading and integrating external 3rd party vendor data into Enterprise MDM.

Proposed

BR-DSC-008 The Contractor shall configure and implement MDM System to accept any inbound data that meets the Enterprise MDM Data Quality rules.

Proposed

BR-DSC-009 The Contractor shall configure and implement MDM System to reject any inbound data that does not meet the Enterprise MDM Data Quality rules.

Proposed

BR-DSC-010 The Contractor shall configure and implement MDM System to maintain a log of all the rejected data in an accessible repository for the Data Steward (or delegate) to review.

Proposed

BR-DSC-011 The Contractor shall configure and implement MDM System for the Data Steward to prioritize and manage remediation of rejected data.

Proposed

BR-DSC-012 The Contractor shall configure and implement MDM System to monitor and manage data quality issues until resolved through standard dashboard(s) and/or reports for the Data Stewards (or delegates).

Proposed

BR-DSC-013 The Contractor shall configure and implement MDM System to provide the Data Stewards (or delegates) the ability to create custom dashboards and/or reports for data quality issues.

Proposed

Offeror Response

BR-HUB MDM Repository - Enterprise MDM Hub

BR-HUB-001 The Contractor shall configure and implement MDM System to create and maintain a unique Enterprise MDM Golden record with most accurate data (for e.g., Identification, Name, Address, Demographics, Contact information, Relationships with other entities / providers, Interactions with other entities / providers) for each “Individual” and “Business” entity from source systems.

Proposed

BR-HUB-002 The Contractor shall configure and implement MDM System to maintain persistently, the Individual or Business attributes respectively from one or more source records used to create or update the Enterprise MDM Golden record.

Proposed

BR-HUB-003 The Contractor shall configure and implement MDM System to generate a unique identifier (Enterprise Individual ID for Individuals and Enterprise Business ID for Businesses) upon creation of an Enterprise MDM Golden record.

Proposed

BR-HUB-004 The Contractor shall configure and implement MDM System to maintain a registry of cross reference identifiers of source system record(s) associated with the Enterprise MDM Golden record.

Proposed

Offeror Response

BR-RFD MDM Repository - Master Reference Data (e.g. look-up data)

BR-RFD-001 The Contractor shall implement MDM System to maintain a persistent repository of Reference data required to support Individual and Business Master Data domains.

Proposed

BR-RFD-002 The Contractor shall implement MDM System to identify and verify the validity and accuracy of the ProposedState of Ohio Department of Administrative Services, Office of Information TechnologySupplement 1-Enterprise MDM Requirements, System Development Methodology and Staffing Requirements RFP 0A1213 Page 18


individual and business attributes. The aforesaid data attributes shall include date, time, system info, how was it verified and user/system that verified it.

Offeror Response

BR-DMG MDM Data Migration / Conversion – General BR-DMG-001 The Contractor shall implement MDM System to have a consistent methodology/implementation to

perform bulk load of historical data (including complex transformations) from source systems into Enterprise MDM for both the Individual and Business Master Data domains.

Proposed

BR-DMG-002 The Contractor shall implement MDM System to have a consistent methodology/implementation to manage scenarios where new Master Reference Data is identified during the Bulk Load process.

Proposed

Offeror Response

BR-DMI MDM Data Migration / Conversion - Individual

BR-DMI-001 The Contractor shall evaluate Individual (Client) Data from Ohio Benefits in the current MDM system to design and implement migration/conversion changes interfacing with Enterprise MDM.

Proposed

BR-DMI-002 The Contractor shall evaluate Individual Data from Master Client Index (MCI) in the current MDM system to design and implement migration/conversion changes interfacing with Enterprise MDM.

Proposed

BR-DMI-003 The Contractor shall evaluate Individual (Recipient) Data from MMIS system to design and implement migration/conversation changes (if necessary) into Enterprise MDM.

Proposed

BR-DMI-004 The Contractor shall migrate Individual (Claimant) Data from OJI into Enterprise MDM. Proposed

BR-DMI-005 The Contractor shall migrate Individual (Seeker) Data from OWCMS into Enterprise MDM. Proposed

BR-DMI-006 The Contractor shall convert Individual Data from all named source systems into Enterprise MDM conforming to Enterprise MDM requirements, data quality rules and standards.

Proposed

Offeror Response

BR-DMB MDM Data Migration / Conversion - Business BR-DMB-001 The Contractor shall migrate Business (Provider, Payor) Data from MMIS into MDM. Proposed

BR-DMB-002 The Contractor shall migrate Business (Vendor, Customer) Data from OAKS into MDM. Proposed

BR-DMB-003 The Contractor shall evaluate Business Data from Master Provider Index (MPI) in the current MDM system to design and implement migration/conversion changes interfacing with Enterprise MDM.

Proposed

BR-DMB-004 The Contractor shall migrate Business (Provider, Vendor) Data from IDM into MDM (Future scope). Proposed

BR-DMB-005 The Contractor shall migrate Business (Employer) Data from Ohio Business Gateway into MDM (Future scope).

Proposed

BR-DMB-006 The Contractor shall convert Business Data from all named source systems into MDM conforming to MDM requirements, data quality rules and standards.

Proposed

Offeror Response



BR-MTC MDM Matching (De-duplication)

BR-MTC-001 The Contractor shall implement MDM System with a reusable, multi-algorithm approach to identifying candidate duplicate records (matching rules) for both the Individual and Business Master Data Domains.> Algorithms shall be designed so that they can be used unchanged for both batch and real-time processes.> Algorithms shall be designed to be used for specific purposes (e.g., only for batch or only real-time processes).> Algorithms shall become progressively less precise in terms of identifying candidate matches, progressing from deterministic (i.e. 'exact') matching through to fully probabilistic (i.e. 'fuzzy') matching.> Algorithms shall cover any data issues with phonetic spellings or partial fields.

Proposed

BR-MTC-002 The Contractor shall implement MDM System Matching algorithms to provide a matching score that is indicative of the quality of the match identified.

Proposed

BR-MTC-003 The Contractor shall implement MDM System for Data Stewards (or a delegate) to configure the actions resulting from a range of match score(s), such as (a) definite (exact) matches (b) candidate (potential) matches or (c) no match.

Proposed

BR-MTC-004 The Contractor shall implement MDM System for Data Stewards to draft changes to data Matching rules.

Proposed

BR-MTC-005 The Contractor shall implement MDM System with ability to apply Matching algorithm changes with flexible option to execute either in future or retroactively on existing (all or a subset of) records around peak usage times and maintenance schedules.

Proposed

BR-MTC-006 The Contractor shall implement MDM System to historically track when two or more records are reviewed and rejected as candidate (potential) matches then omit these records from future matching results.

Proposed

BR-MTC-007 The Contractor shall implement MDM System to require a minimum number of attributes to assess a match for Individual Master Data (e.g. First Name, Last Name, Date of Birth and Sex).

Proposed

BR-MTC-008 The Contractor shall implement MDM System to require a minimum number of attributes to assess a match for Business Master Data (e.g. Business Name and Business Address).

Proposed

BR-MTC-009 The Contractor shall implement MDM System to trigger systematic matching based on establishing matching algorithm after every record creation/addition, change/update, Merge, Unmerge (Split), manual edit etc.

Proposed

BR-MTC-010 The Contractor shall implement MDM System to track the matching algorithm used to match records, so that any issues with matching can be quickly assessed and remediated.

Proposed

BR-MTC-011 The Contractor shall implement MDM System to create a workflow task for the Data Steward (or delegate) to review "candidate" (potential) matches.

Proposed

BR-MTC-012 The Contractor shall implement MDM System to send electronic notification to the Data Steward (or delegate) to review "candidate" (potential) matches.

Proposed

BR-MTC-013 The Contractor shall implement MDM System to process "no match" records as a singleton. Proposed

Offeror Response

BR-MRG MDM MergeBR-MRG-001 The Contractor shall implement MDM System for Data Stewards (or delegates) to configure Merge

rules to optimize the Golden record; > Apply Trust rules based on the perceived Source System Data Quality (e.g., accuracy, currency, completeness etc.) > Trust rules shall be configurable for a single field, a group of fields or the entire record

Proposed

BR-MRG-002 The Contractor shall implement MDM System to systematically Merge "definite" (exact) match records in Enterprise MDM based on predefined Merge rules.

Proposed

BR-MRG-003 The Contractor shall implement MDM System to create workflow tasks for Data Steward (or delegate) to review records for Merge.

Proposed

BR-MRG-004 The Contractor shall implement MDM System to send electronic notification to the Data Steward (or delegate) to review Merge requests.

Proposed

BR-MRG-005 The Contractor shall implement MDM System for Data Steward (or delegate) to review and Proposed



confirm/reject the need for Merging records.BR-MRG-006 The Contractor shall implement MDM System for Data Steward (or delegate) to Merge records that

are manually identified as "definite" (exact) match records.Proposed

BR-MRG-007 The Contractor shall implement MDM System for Data Steward (or delegate) to manually initiate a records Merge via Enterprise MDM UI.

Proposed

BR-MRG-008 The Contractor shall implement MDM System with option to add a workflow task for a Data Steward (or a delegate) to review the results of the systematic Merge process (e.g., Golden record review).

Proposed

Offeror Response

BR-UNM MDM Unmerge (Split)BR-UNM-001 The Contractor shall implement MDM System for Data Stewards (or delegates) to configure

Unmerge (Split) rules to optimize the Golden record; > Apply Trust rules based on the perceived Source System Data Quality (e.g., accuracy, currency, completeness etc.) > Trust rules shall be configurable for a single field, a group of fields or the entire record

Proposed

BR-UNM-002 The Contractor shall implement MDM System to create workflow task(s) for Data Steward (or delegate) to review Unmerge (Split) request(s) of previously Merged record(s).

Proposed

BR-UNM-003 The Contractor shall implement MDM System to send electronic notification to the Data Steward (or delegate) to review Unmerge (Split) requests.

Proposed

BR-UNM-004 The Contractor shall implement MDM System for Data Steward (or delegate) to review and confirm/reject the need for Unmerging (Splitting) previously Merged records.

Proposed

BR-UNM-005 The Contractor shall implement MDM System to systematically Unmerge (Split) records that are identified as incorrect Merges, to the original individual record state.

Proposed

BR-UNM-006 The Contractor shall implement MDM System to systematically apply all manual edits specific to each Unmerged (Split) record that were previously applied to the Merged record.

Proposed

BR-UNM-007 The Contractor shall implement MDM System for Data Steward (or delegate) to Unmerge (Split) records that are manually identified as incorrect Merges, to the original individual record state.

Proposed

BR-UNM-008 The Contractor shall implement MDM System for Data Steward (or delegate) to manually re-apply all manual edits specific to each Unmerged (Split) record that were previously applied to the Merged record.

Proposed

BR-UNM-009 The Contractor shall implement MDM System for Data Steward (or delegate) to manually initiate an Unmerge (Split) a record via Enterprise MDM UI.

Proposed

BR-UNM-010 The Contractor shall implement MDM System to systematically reapply Merge rules to determine a new set of Golden record values for each new composite.

Proposed

BR-UNM-011 The Contractor shall implement MDM System with option to add a workflow task for a Data Steward (or a delegate) to review the results of the systematic Unmerge (Split) process (e.g., Golden record review).

Proposed

BR-UNM-012 The Contractor shall implement MDM System to systematically update the corresponding System Identifier cross references registry.

Proposed

BR-UNM-013 The Contractor shall implement MDM System to historically track Unmerge (Split) and exclude the Unmerged records from future match results.

Proposed

BR-UNM-014 The Contractor shall implement MDM System to make all the Unmerged records available to any Enterprise MDM downstream consuming system(s).

Proposed

Offeror Response

BR-STW MDM Stewardship

BR-STW-001 The Contractor shall implement MDM System to create workflow task(s) for Data Steward (or delegate) to review Enterprise MDM record(s) change request(s).

Proposed



BR-STW-002 The Contractor shall implement MDM System to send electronic notification to the Data Steward (or delegate) to review Enterprise MDM record(s) change requests.

Proposed

BR-STW-003 The Contractor shall implement MDM System to provide Data stewards with the capability to remediate data quality issues (e.g., duplicates, incorrect Merges, missing fields, etc.).

Proposed

BR-STW-004 The Contractor shall implement MDM System to provide Data stewards with the capability to monitor to-do/task lists, their status (based on Key Performance Indicators (KPIs)) and management tools to delegate and transfer task assignments to ensure effective action(s).

Proposed

BR-STW-005 The Contractor shall implement MDM System to enable Data Steward to assign priorities and service level agreements (SLA) on task(s) and delegate resolution to team resources, and provide direction via comments or notes applied to the task.

Proposed

BR-STW-006 The Contractor shall implement MDM System to provide Data stewards with the capability to escalate issues and tasks (e.g., Situations like "Out of Office", need decision/resolution on an issue).

Proposed

BR-STW-007 The Contractor shall implement MDM System to provide Data Stewards to display all open tasks, such as Match-Merge, Split, data quality checks, data stewardship audit and performance etc. with dashboard(s) and/or reports.

Proposed

BR-STW-008 The Contractor shall implement MDM System with the ability for Data Steward to track progress on assigned tasks (e.g., workflow throughput per user).

Proposed

BR-STW-009 The Contractor shall implement MDM System with the ability for Data Steward to audit and report on the usage of Enterprise MDM data.

Proposed

BR-STW-010 The Contractor shall implement MDM System with the ability for Data Steward to review data quality metrics including duplicate analysis (e.g., match results and approvals), address validation, percentage of matches by match algorithm, etc.

Proposed

BR-STW-011 The Contractor shall implement MDM System with the ability for Data Steward to review all changes made (e.g., data quality, manual authoring, survivorship, etc.) to a record within the Enterprise MDM.

Proposed

BR-STW-012 The Contractor shall implement MDM System with the ability for Data Steward to view relevant non-master data within one or more source/target systems, which would enable remediation activities to occur in order to successfully complete the Merge/Split/update of master data records.

Proposed

Offeror Response

BR-SRC MDM Search Capabilities

BR-SRC-001 The Contractor shall implement MDM System to provide search capability to assist users based on their access privileges in searching and finding the record(s) they are interested in.

Proposed

BR-SRC-002 The Contractor shall implement MDM Search capability to perform deterministic search, probabilistic (fuzzy) search, phonetic (e.g., Soundex) search, value ranges (e.g., dates, ages, zip codes, etc.) search, partial field search and searches based on common nicknames (e.g., Peggy for Margaret), common abbreviations and transposed characters and fields, etc.

Proposed

BR-SRC-003 The Contractor shall implement MDM Search capability to enable users to search different types of records in Enterprise MDM (e.g., Individual, Business, Task, Golden record, Source system specific record etc.).

Proposed

BR-SRC-004 The Contractor shall implement MDM Search capability to enable user to perform single or multi-parameter searches.

Proposed

BR-SRC-005 The Contractor shall implement MDM Search capability to provide a score representing the degree of accuracy of the search results.

Proposed

BR-SRC-006 The Contractor shall implement MDM Search capability to keep a historical search log (who performed the search, what data was provided back, when was it searched, what search parameters led to the display of the search etc.).

Proposed

BR-SRC-007 The Contractor shall implement MDM Search capability with the ability to change one or more search criteria and resubmit the search request.

Proposed

BR-SRC-008 The Contractor shall implement MDM Search capability to return only basic information and upon further request provide detailed information.

Proposed

BR-SRC-009 The Contractor shall implement MDM Search capability to provide display options (e.g., Number of records per page etc.) to display the search results in one or more pages with page level navigation capabilities.

Proposed



BR-SRC-010 The Contractor shall implement MDM Search capability to provide option to limit the number of records returned after sorting and filtering criteria are applied, as part of the search result.

Proposed

BR-SRC-011 The Contractor shall implement MDM Search capability with the ability to sort search results based on one or more fields.

Proposed

BR-SRC-012 The Contractor shall implement MDM Search capability with the ability to filter search results based on one or more criteria provided by the user.

Proposed

BR-SRC-013 The Contractor shall implement MDM Search capability with options to select one or more records for further action (e.g., Create, Update, Delete, Merge, Split/Unmerge etc.).

Proposed

BR-SRC-014 The Contractor shall implement MDM Search capability with options to export (for e.g., Excel, CSV, PDF etc.), download, print the search results, etc.

Proposed

Offeror Response

BR-SEC MDM Role based security (Visibility rules)BR-SEC-001 The Contractor shall implement MDM System with the ability to add, delete, change and view local

accounts within Enterprise MDM applications where applicable.Proposed

BR-SEC-002 The Contractor shall implement MDM System to provide role based security at record level, column/field level, source system level, business domain level, record type, etc.

Proposed

BR-SEC-003 The Contractor shall implement MDM System to provide role based security and access to the hierarchy of Data Stewards to login, search/view, create/add, update, delete etc. on source system records and Enterprise MDM Golden records.

Proposed

BR-SEC-004 The Contractor shall implement MDM System to provide role based security and access to the hierarchy of Data Stewards to login, search/view, create/add, update, delete, delegate, assign, prioritize, transfer, monitor, etc. on Enterprise MDM tasks.

Proposed

BR-SEC-005 The Contractor shall implement MDM System with capability to send warning and/or error messages upon security violations.

Proposed

BR-SEC-006 The Contractor shall implement MDM System with capability to assign the role based security permissions for specific users, groups, etc.

Proposed

BR-SEC-007 The Contractor shall implement MDM System with capability to assign the role based security permissions individually or mass update via batch process.

Proposed

BR-SEC-008 The Contractor shall implement MDM System with capability to display and filter specific records, fields etc. based on role permissions.

Proposed

BR-SEC-009 The Contractor shall implement MDM System with capability to optionally mask data for display based on field level (one or more fields) security requirements.

Proposed

BR-SEC-010 The Contractor shall implement MDM System for Data Steward (or delegate) to track and report on new/current Enterprise MDM accesses granted to users, roles, applications/solutions via Enterprise MDM UI.

Proposed

BR-SEC-011 The Contractor shall implement MDM System to support “break-the-glass” or override access to the Enterprise MDM applications and data for State authorized users.

Proposed

Offeror Response

BR-CAU MDM Data Authoring using MDM UI (Create, Read, Update, Delete)BR-CAU-001 The Contractor shall implement MDM System for a Data Steward (or delegate) with the ability to

manually Create, Update, Delete and View Individual and Business data via the Enterprise MDM UI.Proposed

BR-CAU-002 The Contractor shall implement MDM System for a Data Steward (or delegate) with the ability to manually Create, Update, Delete and View mass quantities of Individual and Business data records via the Enterprise MDM UI.

Proposed

BR-CAU-003 The Contractor shall implement MDM System for a Data Steward (or delegate) with the ability to perform mass updates on specific attributes across multiple records with the same data value(s) via

Proposed



the Enterprise MDM UI.BR-CAU-004 The Contractor shall implement MDM System for a Data Steward (or delegate) with the ability to

manually Create, Update, Delete and View mass quantities of Individual and Business data records by importing data from a defined data source (e.g., flat file, database table, etc.).

Proposed

BR-CAU-005 The Contractor shall implement MDM System for a Data Steward (or delegate) with the ability to perform mass updates on specific attributes across multiple records with the same data value(s) by importing data from a defined data source (e.g., flat file, database table, etc.).

Proposed

BR-CAU-006 The Contractor shall implement MDM System to maintain a separate Individual or Business source record(s) that are created manually by the Data Steward (or delegate) directly in the Enterprise MDM system (with source as MDM Data Steward) that are used to create the Enterprise MDM Golden record.

Proposed

Offeror Response

BR-NMI MDM Data Authoring using non-MDM UI (Create, Read, Update, Delete) - IndividualBR-NMI-001 The Contractor shall design and implement the appropriate MDM implementation style (i.e. registry,

consolidation, co-existence, transaction) to interface the Ohio Benefits systems with the Enterprise MDM System for Individual (Client) Data.

Proposed

BR-NMI-002 The Contractor shall design and implement the appropriate MDM implementation style (i.e. registry, consolidation, co-existence, transaction) to interface the MMIS system with the Enterprise MDM system for Individual (Recipient) Data.

Proposed

BR-NMI-003 The Contractor shall design and implement the appropriate MDM implementation style (i.e. registry, consolidation, co-existence, transaction) to interface the OJI system with the Enterprise MDM system for Individual (Claimant) Data.

Proposed

BR-NMI-004 The Contractor shall design and implement the appropriate MDM implementation style (i.e. registry, consolidation, co-existence, transaction) to interface the OWCMS system with the Enterprise MDM system for Individual (Seeker) Data.

Proposed

BR-NMI-005 The Contractor shall populate the MDM System with the above systems Individual Data into Enterprise MDM in real time / near real time and/or on a scheduled and periodic basis.

Proposed

BR-NMI-006 The Contractor shall populate the MDM System with the above systems Individual Data singularly or as a mass data migration via batch processing.

Proposed

BR-NMI-007 The Contractor shall implement MDM System to maintain each Individual source system record separately that are used to create the Enterprise MDM Golden record.

Proposed

BR-NMI-008 The Contractor shall implement MDM System to restrict systematic changes to business defined immutable attributes (e.g., SSN, TIN etc.) for Individual data.

Proposed

BR-NMI-009 The Contractor shall implement MDM System to generate electronic error notifications/alerts in case of systematic updates to restricted immutable information for Individual data.

Proposed

BR-NMI-010 The Contractor shall implement MDM System to generate electronic warning notifications/alerts in case of systematic updates to permissible immutable information for Individual data.

Proposed

Offeror Response

BR-NMB MDM Data Authoring using non-MDM UI (Create, Read, Update, Delete) - BusinessBR-NMB-001 The Contractor shall design and implement the appropriate MDM implementation style (i.e. registry,

consolidation, co-existence, transaction) to interface the MMIS system with the Enterprise MDM system for Business (Provider, Payor) Data.

Proposed

BR-NMB-002 The Contractor design and implement the appropriate MDM implementation style (i.e., registry, consolidation, co-existence, transaction) to interface the OAKS system with the Enterprise MDM system for Business (Vendor, Customer) Data.

Proposed

BR-NMB-003 The Contractor shall design and implement the appropriate MDM implementation style (i.e., registry, consolidation, co-existence, transaction) to interface the Ohio Business Gateway system with the

Future



Enterprise MDM system for Business (Employer) Data (Future scope).

BR-NMB-004 The Contractor shall design and implement the appropriate MDM implementation style (i.e., registry, consolidation, co-existence, transaction) to interface the IDM system with the Enterprise MDM system for Business (Provider, Vendor) Data (Future scope).

Future

BR-NMB-005 The Contractor shall populate the MDM System with the above systems Business Data in real time / near real time and/or on a scheduled and periodic basis.

Proposed

BR-NMB-006 The Contractor shall populate the MDM System with the above systems Business Data singularly or as a mass data migration via batch processing.

Proposed

BR-NMB-007 The Contractor shall implement MDM System to maintain each Business source system record separately that are used to create the Enterprise MDM Golden record.

Proposed

BR-NMB-008 The Contractor shall implement MDM System to restrict systematic changes to business defined immutable attributes (e.g., TIN, Business Type etc.) for Business data.

Proposed

BR-NMB-009 The Contractor shall implement MDM System to generate electronic error notifications/alerts in case of systematic updates to restricted immutable information for Business data.

Proposed

BR-NMB-010 The Contractor shall implement MDM System to generate electronic warning notifications/alerts in case of systematic updates to permissible immutable information for Business data.

Proposed

Offeror Response

BR-RDA MDM Master Reference Data Authoring (Create, Read, Update, Delete)BR-RDA-001 The Contractor shall implement MDM System for a Data Steward (or delegate) to Create, Update,

View and Delete Master Reference Data via Enterprise MDM User Interface (UI).Proposed

BR-RDA-002 The Contractor shall implement MDM System for a Data Steward to monitor requests (create, update, delete), review and approval of Master Reference Data changes via Enterprise MDM UI.

Proposed

BR-RDA-003 The Contractor shall implement MDM System to store active, historical and pending Master Reference Data.

Proposed

BR-RDA-004 The Contractor shall implement MDM System to allow only active Master Reference Data to be assigned to Master Data records.

Proposed

BR-RDA-005 The Contractor shall implement MDM System for historical Master Reference Data to maintain links with historical (e.g., deactivated) Master Data Records.

Proposed

BR-RDA-006 The Contractor shall configure and implement MDM System to maintain a registry of system identifiers for Source and Target systems associated with the Enterprise MDM Golden record(s).

Proposed

BR-RDA-007 The Contractor shall implement MDM System with the ability to upload file based Master Reference Data changes for the following scenarios at a minimum:> full re-load> partial update> new records only> deletions only, etc.

Proposed

BR-RDA-008 The Contractor shall implement MDM System to prevent Master Reference Data from being deactivated/deleted when it is associated with one or more active Master Data record(s).

Proposed

BR-RDA-009 The Contractor shall implement MDM System with the ability to accept and manage new Reference Data values identified during batch conversion processes.

Proposed

BR-RDA-010 The Contractor shall implement MDM System with the ability to accept and manage duplicate Reference Data values with differences from various source systems.

Proposed

Offeror Response

BR-SYC MDM Data Synchronization/Harmonization (Notifications/Alerts)BR-SYC-001 The Contractor shall implement MDM System to support batch, real-time and near real-time Proposed



distribution of data, which will encompass applications that pull or have data pushed to them due to occurrence of Enterprise MDM changes (e.g. Merge, Unmerge, Authoring updates, etc.)

BR-SYC-002 The Contractor shall implement MDM System to send electronic notification(s) to a queue for all the source/target/downstream systems to consume (Pull or Push) for each of the following scenarios including (but not limited to):> Creation/Addition of a new Individual or Business Golden record in Enterprise MDM> Update/Change to an Individual or Business Golden record in Enterprise MDM> Merge of Individual or Business Golden record in Enterprise MDM> Unmerge (Split) of Individual or Business Golden record in Enterprise MDM> Deletion/Deactivation of Individual or Business Golden record in Enterprise MDM

Proposed

BR-SYC-003 The Contractor shall implement MDM System to send electronic notification(s) to a queue only for specific source/target/downstream systems to consume for each of the following scenarios including (but not limited to):> Creation/Addition of a new Individual or Business source record in Enterprise MDM from specific source system> Update/Change to an Individual or Business source record in Enterprise MDM from specific source system> Merge of Individual or Business source record in Enterprise MDM from specific source system> Unmerge (Split) of Individual or Business source record in Enterprise MDM from specific source system> Deletion/Deactivation of Individual or Business source record in Enterprise MDM from specific source system

Proposed

BR-SYC-004 The Contractor shall implement MDM System to send electronic notifications to a queue in a "fire and forget" manner i.e. no follow up action is required for unconsumed messages.

Proposed

BR-SYC-005 The Contractor shall implement MDM System electronic notification(s) to include following information (but not limited to):> Enterprise MDM generated unique identifier (Enterprise Individual ID for Individuals and Enterprise Business ID for Businesses)> Source system unique identifier, if the notification is for a specific system> Individual or Business data that was added/changed/deleted/deactivated/merged/unmerged (split)

Proposed

BR-SYC-006 The Contractor shall implement MDM System to send electronic notifications in (near) real time and scheduled batch.

Proposed

BR-SYC-007 The Contractor shall implement MDM System to maintain the electronic notifications in the queue for a business specified period of time.

Proposed

Offeror Response

BR-ANL MDM AnalyticsBR-ANL-001 The Contractor shall implement MDM System to provide a Data Quality Dashboard for Data

Steward to proactively monitor Enterprise MDM data quality. Proposed

BR-ANL-002 The Contractor shall provide the following details in the Data Quality Dashboard including (but not limited to): > Total matched records in each Data Domain> Total count of source system records and unique Golden records in Enterprise MDM for each Data Domain> Total records approved in 1 day, 1 week, 1 month, 1 quarter> List of all new Master Reference Data codes added during a configurable period of time, and their source (manual or systematic record creations through batch processing)

Proposed

BR-ANL-003 The Contractor shall provide the following details for the monitoring purpose in the Data Quality Dashboard including (but not limited to): > Track progress on corrective actions individually, by resource and overall for the domain> Data Quality Metrics> Data Freshness> Data Volumes> Throughput Volumes > Display which rules are used by Enterprise MDM by frequency and preference and to provide suggested enhancements to such business rules> Analytics and performance measures related to a range of processes and activities taking place within Enterprise MDM, from the running of batch data loads to the execution of workflows against

Proposed



benchmarks to the data quality of active client data in the Enterprise MDM. This metadata includes information such as scoring on matches, number of records compared, etc.

BR-ANL-004 The Contractor shall implement MDM System to provide a System Performance Dashboard for Data Steward to proactively monitor MDM system. Dashboard will provide key performance details including (but not limited to): > Enterprise MDM system performance> Enterprise MDM process performance> Enterprise MDM component (Cleansing, Standardization, Matching, Merging, Unmerging (Splitting), Search etc.) execution performance, etc.

Proposed

Offeror Response

BR-GDD MDM Business Glossary / Data Dictionary / MetadataBR-GDD-001 The Contractor shall configure and implement Informatica Business Glossary to document agency

and system specific terms, definitions, standards for each Critical Data Elements in the Enterprise MDM Data Domains.

Proposed

BR-GDD-002 The Contractor shall configure and implement Informatica Business Glossary to enable workflow to harmonize terms and definitions across all agencies and systems to establish an enterprise set of terms, definitions and standards, which will be the basis for the Enterprise MDM solution.

Proposed

BR-GDD-003 The Contractor shall implement Informatica Metadata Manager to maintain the Informatica Business Glossary by regularly updating the business glossary changes to provide complete consistency and transparency of business terms and definitions across the enterprise.

Proposed

BR-GDD-004 The Contractor shall configure and implement Informatica Metadata Manager to collect and store data lineage from the source systems through Enterprise MDM to target systems as well as define a process to manage the data on an ongoing basis.

Proposed

BR-GDD-005 The Contractor shall populate and maintain the data lineage from the source systems through Enterprise MDM to target systems in Informatica Metadata Manager, on an ongoing basis.

Proposed

Offeror Response


BR-AUD MDM Data / Historical AuditingBR-AUD-001 The Contractor shall implement MDM process to maintain all business rules (cleansing, matching,

merging, etc.), and how the rules have been applied within Enterprise MDM with sufficient visibility to satisfy a timely audit review process.

Proposed

BR-AUD-002 The Contractor shall implement MDM System for Data Steward (or delegate) with on-demand access to all the functional logs (e.g., Security change log, Data Steward change log, Reference data change log, etc.) for follow-up action through Enterprise MDM UI.

Proposed

BR-AUD-003 The Contractor shall implement MDM System and processes to maintain a history of all data changes (Add, Update, Delete, Unmerge (Split), Merge etc.) in a change log with the following sample details:> The before and after view of the data change > System ID/User ID of the system/user that made the change> How the change was made (batch, online, UI, data services, direct access, etc.) > Date and Time of the change

Some example data changes are attribute level changes, record level changes, reference data changes, to-do/task changes, role based security changes, Informatica Business Glossary, Data Dictionary and Metadata changes.

Proposed

BR-AUD-004 For financial, operational, compliance and legal reasons, the Contractor shall implement MDM System and processes to capture and maintain a history of all system/user Enterprise MDM activities in an activity log with the following sample details: > System ID/User ID of the system/user that interacted with Enterprise MDM

Proposed



> What the system/user interacted for (with criteria used for interaction)> How the interaction was made (batch, online, UI, data services, direct access, etc.)> Date and Time of the activity, etc.

Some example activities are data profiling, data search and view.

BR-AUD-005 The Contractor shall implement MDM System and processes to query, search and report based on criteria like date ranges, user groups, users, system(s), etc. on the historical change and activity logs respectively to identify and monitor any abnormal usage patterns.

Proposed

BR-AUD-006 The Contractor shall implement MDM System and processes to maintain the historical change and activity logs for a State specified period of time.

Proposed

BR-AUD-007 The Contractor shall implement MDM System and processes to export change and activity logs into text format in such a manner as to allow correlation based on time (e.g., Coordinated Universal Time [UTC] synchronization). The Solution shall have the ability to format recorded time stamps using UTC based upon ISO 8601.

Proposed

BR-AUD-008 The Contractor shall implement MDM System to grant read access to the change and activity logs to only those authorized users with explicit read access privilege.

Proposed

BR-AUD-009 The Contractor shall implement MDM System and processes to protect the stored change and activity logs from unauthorized modifications and deletions.

Proposed

BR-AUD-010 The Contractor shall implement MDM System and processes to provide the ability for an authorized administrator to set the inclusion or exclusion of auditable events based on organizational policy & operating requirements/limits.

Proposed


3.6 Data Requirements: “Individual” DomainNote: For section 3.6, Offerors can address the Data Element Requirements at the end of this section. Offerors do not have to address each Data Element Requirement individually.

Dat

a R

EQ

ID

Data Element Name Description Status Business Data Type

Sou

rce

Sys

tem

Ref

eren

ce D

ata

Can

dida

te

Mul

tiple

Val

ues

Per

mis

sibl

e

Fiel

d is

Can

dida

te

for u

se in

M

atch

ing

DE-I1 Enterprise Individual ID The key assigned via the Enterprise MDM solution, representing a unique Individual

Proposed

DE-I2 Prefix The prefix of the Individual Proposed Character (String) Yes YesDE-I3 First Name The first name of the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits,

OJI, OWCMS Yes

DE-I4 Middle Name The middle name of the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits, OJI, OWCMS

DE-I5 Last Name The last name of the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits, OJI, OWCMS

Yes

DE-I6 Previous Last Name / Maiden Name

The previous last name of the Individual due to marriage, adoption, etc.

Proposed Character (String) OJI, Ohio Benefits Yes Yes

DE-I7 Suffix The suffix of the Individual Proposed Character (String) Ohio Benefits Yes Yes YesDE-I8 Sex / Gender The sex/gender of the Individual Proposed Character (String) OJI, OWCMS Yes YesDE-I9 Date of Birth The date of birth of the Individual Proposed Date MCI, MMIS, Ohio Benefits,

OJI, OWCMS Yes

DE-I10 Deceased Indicator Indicator tells whether the Individual is deceased or not Proposed True/False OJIDE-I11 Date of Death The date of death of the Individual Proposed Date MMISDE-I12 Marital Status Indicates tells whether the Individual is married,

divorced, etc.Proposed Character (String) MMIS Yes

DE-I13 Phone Number The phone number of the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits, OJI, OWCMS

Yes Yes

DE-I14 Phone Number extension

The phone number extension of the Individual Proposed Character (String) OJI, OWCMS Yes

DE-I15 Phone Number Type The type of phone number (e.g., work, personal, etc.) provided by the Individual

Proposed Character (String) OJI, Ohio Benefits Yes Yes

DE-I16 Address Type The type of address provided by the Individual Proposed Character (String) MCI, Ohio Benefits, OJI YesDE-I17 Address Line 1 The first line of the address provided by the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits,

OJI, OWCMSYes Yes

DE-I18 Address Line 2 The second line of the address provided by the Individual

Proposed Character (String) MCI, MMIS, Ohio Benefits, OJI, OWCMS

Yes Yes


Dat

a R

EQ

ID


Sou

rce

Sys

tem

Ref

eren

ce D

ata

Can

dida

te

Mul

tiple

Val

ues

Per

mis

sibl

e

Fiel

d is

Can

dida

te

for u

se in

M

atch

ing

DE-I19 Address Line 3 The third line of the address provided by the Individual Proposed Character (String) MCI, MMIS Yes YesDE-I20 City The city corresponding to the Individual's address Proposed Character (String) MCI, MMIS, Ohio Benefits,

OJI, OWCMSYes Yes Yes

DE-I21 County The county corresponding to the Individual's address Proposed Character (String) OJI, OWCMS Yes YesDE-I22 State / Region The State corresponding to the Individual’s address Proposed Character (String) OJI, OWCMS Yes Yes YesDE-I23 Zip The Zip code corresponding to the Individual's address Proposed Character (String) MCI, MMIS, Ohio Benefits,

OJI, OWCMSYes Yes

DE-I24 Zip4 The Zip plus 4 corresponding to the Individual's address


Yes Yes

DE-I25 Country The country corresponding to the Individual’s address Proposed Character (String) OJI Yes YesDE-I26 Valid Address Flag Indicator of whether the address is valid Proposed True/False MCI, Ohio Benefits,

OWCMSYes

DE-I27 Longitude Geographical Longitude of the Individual's address Proposed Decimal MCI, MMIS, Ohio Benefits YesDE-I28 Latitude Geographical Latitude of the Individuals' address Proposed Decimal MCI, MMIS, Ohio Benefits YesDE-I29 Email Address The email address of the Individual Proposed Character (String) OJI, OWCMS Yes YesDE-I30 Email Type The type (e.g., work, personal) of email provided by the

IndividualProposed Character (String) OJI Yes Yes

DE-I31 Birth City The city corresponding to where the Individual was born

Proposed Character (String) Ohio Benefits Yes

DE-I32 Birth County The county corresponding to where the Individual was born


DE-I33 Birth State/Region The State corresponding to where the Individual was born


DE-I34 Birth Country The country corresponding to where the Individual was born

Proposed Character (String) OJI Yes

DE-I35 US Citizenship Status Indicator for US citizenship of the Individual Proposed Character (String) MMIS, OJI, OWCMS, Ohio Benefits

Yes

DE-I36 Citizenship Documentation Type

The name/type of document provided by the Individual to verify Citizenship Status

Proposed Character (String) OWCMS Yes

DE-I37 Social Security Number The social security number of the Individual Proposed Character (String) MCI, MMIS, Ohio Benefits, OJI, OWCMS

Yes

DE-I38 ID Type The type of identification provided by the Individual (e.g., Driver’s License)

Proposed Character (String) OJI Yes Yes

DE-I39 ID Number The number corresponding to the ID Type provided (e.g., the Driver’s license #)

Proposed Character (String) OJI Yes

DE-I40 ID Issued State The State from which the ID was issued Proposed Character (String) OJI, OWCMS Yes Yes


Dat

a R

EQ

ID


Sou

rce

Sys

tem

Ref

eren

ce D

ata

Can

dida

te

Mul

tiple

Val

ues

Per

mis

sibl

e

Fiel

d is

Can

dida

te

for u

se in

M

atch

ing

DE-I41 ID Issue Date The date the ID was issues Proposed DateDE-I42 ID Expiration Date The date the ID will expire Proposed DateDE-I43 Race The race(s) of the Individual Proposed Character (String) OJI, OWCMS Yes YesDE-I44 Ethnicity The ethnicity(ies) of the Individual Proposed Character (String) OJI, OWCMS Yes YesDE-I45 Relation The relationship link between this Individual and

another IndividualProposed Character (String) OJI Yes

DE-I46 Relationship Type The type of relationship between two Individuals (e.g., parent, sibling, etc.).

Proposed Character (String) OJI Yes Yes

DE-I47 Immigration Document Type

The type of document provided to support immigration status

Proposed Character (String) Yes

DE-I48 Immigration Document Number

The number corresponding to the immigration document provided

Proposed Character (String)

DE-I49 Immigration Date of Entry

The date the Individual entered the country based on immigration documentation provided

Proposed Date

DE-I50 Immigration Document Expiration Date

The date that the immigration document expires Proposed Date OJI, OWCMS

DE-I51 Immigration Status The immigration status of the person Proposed Character (String) YesDE-I52 Country of Citizenship The country corresponding to where the individual has

citizenshipProposed Character (String) OWCMS Yes

DE-I53 Residency Status Self-verification by individual that they are a resident of Ohio, regardless of their mailing or physical address

Proposed True/False

DE-I54 Veteran Status Is this individual a veteran? Proposed Character (String) OJI, OWCMS YesDE-I55 Enlistment Date The date corresponding to when the individual entered

military serviceProposed Date OWCMS

DE-I56 Discharge Date The date corresponding to when the individual left military service

Proposed Date OWCMS

DE-I57 Branch of Service The branch of the military the individual served in. Proposed Character (String) OWCMS YesDE-I58 Discharge Type The type of military discharge by which the individual

left the armed servicesProposed Character (String) Yes

DE-I59 System Name The name of the system where the individual has one or more records

Proposed Character (String) MCI, Ohio Benefits, OJI, OWCMS

Yes Yes

DE-I60 System ID The unique Identifier used to track the individual within a particular system


Yes

Offeror Respons

e



3.7 Data Element Requirements: “Business” Domain Note: For section 3.7, Offerors can address the Data Element Requirements at the end of this section. Offerors do not have to address each Data Element Requirement individually.

Dat

a R

EQ

ID


Sou

rce

Sys

tem

Ref

eren

ce D

ata

Can

dida

te

Mul

tiple

Val

ues

Per

mis

sibl

e

Fiel

d is

Can

dida

te

for u

se in

M

atch

ing

DE-B1 Enterprise Business ID The key assigned via the Enterprise MDM solution, representing a unique Business

Proposed

DE-B2 Business Name Type Indicator for the type of name: legal, corporate, DBA, etc.

Proposed Character (String) MPI, MMIS, OBG, OAKS Yes Yes Yes

DE-B3 Business Name The name associated with “Business Name Type” for the Business

Proposed Character (String) MPI, MMIS, OBG, OAKS Yes Yes

DE-B4 Ownership Type The ownership structure of the business: Corp, LLC, sole proprietor, etc.

Proposed Character (String) MMIS Yes Yes

DE-B5 Address Type The type of address provided by the Business Proposed Character (String) OBG Yes Yes YesDE-B6 Address Line 1 The first line of the address provided by the

BusinessProposed Character (String) MPI, MMIS, OBG Yes Yes

DE-B7 Address Line 2 The second line of the address provided by the Business

Proposed Character (String) MPI, MMIS, OBG Yes Yes

DE-B8 City The city corresponding to the Business's address Proposed Character (String) MPI, MMIS, OBG Yes YesDE-B9 County The county corresponding to the Business’s

addressProposed Character (String) OBG Yes Yes

DE-B10 State The State corresponding to the business's address Proposed Character (String) MPI, MMIS, OBG Yes YesDE-B11 Zip Code The zip code corresponding to the Business's

addressProposed Character (String) MPI, MMIS, OBG Yes Yes

DE-B12 Zip Code +4 The Zip+4 corresponding to the Business's address Proposed Character (String) MMIS Yes YesDE-B13 Phone Number The phone number of the Business Proposed Character (String) MCI, MMIS Yes YesDE-B14 Phone Number Extension The phone number extension of the Business Proposed Character (String) MCI, MMIS YesDE-B15 Phone Number Type The type of phone number (e.g., direct, fax, support,

etc.) provided by the BusinessProposed Character (String) Yes Yes Yes

DE-B16 External Identifier Type The type of external identifier associated with the business (e.g., National Provider ID – NPI, DUNS Number, etc.)

Proposed Character (String) MPI, MIT, Yes

DE-B17 External Identifier The identifier provided to the Business by an Industry, State, Federal or other external organization.

Proposed Character (String) MPI, MMIS, OBG Yes


Dat

a R

EQ

ID


Sou

rce

Sys

tem

Ref

eren

ce D

ata

Can

dida

te

Mul

tiple

Val

ues

Per

mis

sibl

e

Fiel

d is

Can

dida

te

for u

se in

M

atch

ing

DE-B18 Tax Identifier Type The type of registered tax identification number provided by the Business based on its ownership type (e.g., EIN, SSN)

Proposed Character (String) Yes Yes

DE-B19 Tax Identifier The tax identifier used by the Business to file taxes Proposed Character (String) MMIS, OBG YesDE-B20 Parent The Enterprise Business ID representing the

business that is the immediate parent within the business’s organizational hierarchy


DE-B21 Ultimate Parent The Enterprise Business ID representing the highest level within the business’s organizational hierarchy


DE-B22 System Name The name of the system where the Business has one or more records

Proposed Character (String) MPI, MMIS, OBG, OAKS Yes Yes

DE-B23 System ID The unique Identifier (System Assigned Key - SAK) used to track the Business within a system

Proposed Character (String) MPI, MMIS, OBG, OAKS Yes

Offeror Respons

e


3.8 Non-Functional Requirements Note: For section 3.8, Offerors can address the Non-Functional Requirements at the end of each Non-Functional Requirement category. Offerors do not have to address each Non-Functional Requirement individually.

REQ ID Non-Functional Description by CategoryNon-

Functional Requirement

Status

NFR- AUD Audit and Compliance

NFR-AUD-001 The solution shall comply with Ohio's Ohio Revised Code (ORC) Access logging rules for confidential information

Proposed

NFR-AUD-002 The solution shall comply with applicable Federal and State of Ohio’s Audit and Compliance requirements (Please refer to Supplement 2 – Section 5 and 7)

Proposed

NFR-AUD-003 The Solution shall be able to detect security-relevant events that it mediates and generate audit records for them. At a minimum the events shall include those listed here: - start/stop- user login/logout- session timeout- account lockout- scheduling- node-authentication failure- signature created/validated- Personally Identifiable Information (PII) export- PII import- security administration events- backup and restore

Proposed

NFR-AUD-004 The Solution shall audit all access to protected information in real time Proposed

NFR-AUD-005 The Solution shall provide alert mechanism for privacy breaches Proposed

NFR-AUD-006 When “Break-the-Glass” or an override access is performed, the Solution shall maintain a complete and consistent audit trail of the individual who performed the override and the change made (before and after action/state of the record).

Proposed

Offeror Response

NFR- BPM Business Process Modeling (BPM)

NFR-BPM-001 The Solution shall balance application workflow workload (assigned tasks) based upon user and work unit queues.

Proposed

Offeror Response

NFR-CM Consent Management

NFR-CM-001 The Solution shall track acceptance of informed consent or privacy policies where the Individual or Business authorizes the terms and conditions contained in the informed consent and privacy policies. Informed consent may include consent for sharing of personal and program transaction based activities with other Individuals, such as a designated legal representative, or a third-party.

Proposed

Offeror Response




Status

NFR- DI Data Integration

NFR-DI-001 The Solution shall provide tooling for data source connectivity: Adapters for a range of source types beyond Relational Database Management Solutions (RDBMS's) and legacy databases (access to data stored in non-relational structures - for example, VSAM files and IMS databases), including packaged applications and Web services, the ability to access semi-structured and unstructured data (such as e-mail, websites, office productivity tools, content repositories and rich media)and the ability to interpret (as a source) XML structures.

Proposed

NFR-DI-002 The Solution shall provide the ability to load data in a variety of approaches including (but not limited to) the following:- Bulk data extraction and loading- SOA Web Services via near real time integration- Granular trickle-feed acquisition and delivery- Changed-data capture (ability to identify and extract modified data)- Event-based acquisition (time-based or data-value-based)

Proposed

Offeror Response

NFR- IDM Identity Management

NFR-IDM-001 The solution shall leverage the Identity Management solution of the State and State provided User ID’s to support single sign-on capability for all users.

Proposed

NFR-IDM-002 The Solution shall re-authenticate the user before any access to Protected Health Information (PHI) or Personally Identifiable Information (PII) or other sensitive or confidential information is allowed, including when not connected to a network (e.g., on unconnected mobile devices).

Proposed

NFR-IDM-003 Identity management for State and non-State users and systems will be provided by the OIT Identity Management solution. The Solution is required to integrate to the States provided solution which supports industry LDAP standards. (Please refer to Supplement section 7.0 Security Review Services)

Proposed

NFR-IDM-004 The Enterprise MDM solution set of capabilities must be able to provide, at minimum, thefollowing implemented Security Management Services:

*Users' access rights shall be based on what roles they play in the enterprise (State and Counties)and/or what groups they belong to for external entities.*Authentication of user identities — Technology component that verifies the identities of those seekingto access client data. Shall include strong authentication supported by an appropriate infrastructurefor identity and access management.*The solution shall have a mechanism for Annual Reconciliation of users to determine if access is stillneeded.*The authentication and authorization solution shall be ADA compliant.*The solution shall include the capability to monitor activity continually according to a set of predefinedrules, and to notify administrators when abnormal activity is detected (Please refer to Supplement 2 section 7.0 Security Review Services)

Proposed

NFR-IDM-005 The Solution shall enforce a limit of (configurable) consecutive invalid access attempts by a user. The Solution shall protect against further, possibly malicious, user authentication attempts using an appropriate mechanism (e.g., locks the account/node until released by an administrator, locks the account/node for a configurable time-period, or delays the next login prompt according to a configurable delay algorithm).

Proposed

NFR-IDM-006 The Solution shall provide an administrative function that resets passwords leveraging the Identity Management Solution of the State.

Proposed

NFR-IDM-007 When passwords are used, the Solution shall not display passwords while being entered. Proposed

NFR-IDM-008 The Solution shall provide only limited feedback information to the user during the authentication as per the Proposed




StatusIdentity Management Solution rules of the State.

NFR-IDM-009 When passwords are used, the Solution shall allow an authenticated user to change their password consistent with password strength rules in compliance with the Identity Management Solution of the State.

Proposed

NFR-IDM-010 When passwords are used, the Solution shall support password strength rules that allow for minimum number of characters, and inclusion of alpha-numeric complexity, in compliance with the Identity Management Solution of the State.

Proposed

Offeror Response

NFR- IOP Interoperability - Interfaces

NFR-IOP-001 The Solution shall provide a Service Oriented Architecture based infrastructure (i.e., hub and spoke) for connecting to other solutions using an Enterprise Service Bus infrastructure.

Proposed

NFR-IOP-002 The solution's Interface architecture for internal A2A (Application to Application) integration shall not have a negative impact on the user experience and expectation for application performance.

Proposed

NFR-IOP-003 The solution's interfaces shall secure and protect the data and the associated infrastructure from a confidentiality, integrity and availability perspective.

Proposed

NFR-IOP-004 The Solution shall be able to support Application to Application (A2A) asynchronous messaging using web services. The messaging capabilities will be able to support a wide variety of A2A patterns including, but not limited to, the following: - Data look-up and retrieval - Data look-up with services provided by other applications - Simple bulk data transfer to/from other solutions.

Proposed

NFR-IOP-005 The solution's interfaces shall continue to operate despite failure or unavailability of individual technology components such as a server platform or network connection.

Proposed

NFR-IOP-006 The solution's interfaces must be scalable to accommodate changes in scale including changes in user population, transaction volume, throughput and geographical distribution.

Proposed

Offeror Response

NFR- MDM Master Data Management (MDM)

NFR-MDM-001 The Solution shall include integration middleware, including publish and subscribe mechanisms, to provide a communication backbone for the bidirectional flow of client and provider data between the central repository and the spoke solutions, be they copies or subsets of the repository, or remote applications.

Proposed

NFR-MDM-002 The Solution shall provide the ability to integrate the data within the Enterprise MDM with management and security tools.

Proposed

NFR-MDM-028 The Solution shall adhere to the State specified architectural framework and standards e.g., Medicaid Information Technology Architecture (MITA) for Ohio Benefits.

Proposed

Offeror Response




Status

NFR-PER Performance

NFR-PER-001 The Solution shall support either a Production and hot (real time replication) DR design or a multi host site Production design that would allow one site to seamlessly be offline and the other site would maintain service without interruption.

Proposed

NFR-PER-002 The Solution shall include a disaster recovery (DR) plan, including recovery point objective (RPO) and recovery time objective (RTO) as mutually agreed upon with the State. And the DR plan shall provide contingency mechanisms for client lookup capabilities and online collaboration in the event of a disaster.

Proposed

NFR-PER-003 The Solution shall provide the ability to perform archival/incremental backups and the ability to perform open/closed database backups.

Proposed

NFR-PER-004 The Solution shall be available for use 99.9% of the time (no more than 8.8 hours of downtime per year). Proposed

NFR-PER-005 The solution shall be architected with no single point of failure, supporting a high-availability enterprise Proposed

NFR-PER-006 Hours of operations shall be 24 hours per day, 7 days per week, and 365 days a year. Proposed

Offeror Response

NFR-PS Production Support

NFR-PS-001 Upon completion of any maintenance call, the Contractor shall furnish a maintenance activity report to the State within 24 hours, which shall include, at minimum, the following:- Date and time notified.- Date and time of arrival.- If hardware, type and serial number(s) of machine(s).- If software, the module or component name of the affected software code.- Time spent for repair.- List of parts replaced and/or actions taken.- Description of malfunction or defect.

Proposed

NFR-PS-002 The Contractor shall provide the State with a list of personnel, contact information, and their area of expertise of who shall be performing Enterprise MDM solution production support.

Proposed

NFR-PS-003 The Contractor shall repair any corrupted data that is associated with a problem in the Enterprise MDM solution.

Proposed

NFR-PS-004 With concurrence from the State, the routine planned maintenance activities shall be scheduled without disrupting the negotiated operational hours. Contractor shall provide the State with a copy of the schedule at least 30 days in advance of the scheduled maintenance date for approval.

Proposed

NFR-PS-005 The testing tools and test configurations shall be provided to the State as the Enterprise MDM solution are transitioned into support.

Proposed

NFR-PS-006 The Contractor shall provide instructions and training for State support staff that may need to access and support the Enterprise MDM solution remotely (e.g., through PDAs, tablet PC's through a VPN).

Proposed

NFR-PS-007 The Contractor shall develop an automated process for purging production Enterprise MDM solution files when necessary.

Proposed

Offeror Response

NFR-RP Regulatory Policies

NFR-RP-001 The Solution must provide a mechanism to comply with Solution security requirements and safeguards requirements of at least the following Federal agencies / entities:

- Social Security Administration (SSA)- Department of Health & Human Services (DHHS) Center for Medicare & Medicaid Services (CMS)- HHS Administration for Children & Families (ACF)

Proposed




Status- U.S. Department of Education (ED)

NFR-RP-002 The Solution shall conform to the sub-parts of Section 508 of the Americans with Disabilities Act (ADA), Ohio RC4112-05 and any other appropriate State or Federal disability legislation.

Proposed

NFR-RP-003 The Solution will conform and support the Medicaid Information Technology Architecture (MITA) v3.0 or later.

Proposed

NFR-RP-004 The Solution shall be able to adhere to all legal, statutory, and regulatory requirements, as determined by Ohio leadership.

Proposed

NFR-RP-005 The solution shall adhere to Ohio's ORC regarding Personally Identifiable Information (PII) restrictions Proposed

Offeror Response

NFR-SE Scalability & Extensibility

NFR-SE-001 The Solution shall be designed for ease of maintenance and readily allow future functional enhancements. Proposed

NFR-SE-002 The Solution shall be adequately flexible to keep up with ever changing technology and regulatory changes. Proposed

NFR-SE-003 The solution, including programs, database, and ancillary hardware and related software solutions shall be able to retain its performance levels when adding additional users, functions, and data.

Proposed

NFR-SE-004 The Solution shall be scalable and adaptable to meet future growth and expansion needs. Proposed

NFR-SE-005 State shall be able to modify the labels and arrangement of information in the data model Solution documentation templates and can create custom data fields.

Proposed

NFR-SE-006 The Solution shall provide the ability to create and/or modify edits and business rules which determine the correctness/integrity of data.

Proposed

Offeror Response

NFR-SEC Security

NFR-SEC-001 The Solution shall support auditing at the object level (i.e., Table, Column). Proposed

NFR-SEC-002 The Solution upon detection of inactivity of an interactive session shall prevent further viewing and access to the Solution by that session by terminating the session, or by initiating a session lock that remains in effect until the user reestablishes access using appropriate identification and authentication procedures. The inactivity timeout shall be configurable.

Proposed

NFR-SEC-003 The Solution shall enforce a limit of (configurable) consecutive invalid access attempts by a user. The Solution shall protect against further, possibly malicious, user authentication attempts using an appropriate mechanism (e.g., locks the account/node until released by an administrator, locks the account/node for a configurable time-period, or delays the next login prompt according to a configurable delay algorithm).

Proposed

NFR-SEC-004 The Solution shall support grouping users by functional departments or other organization to simplify security maintenance.

Proposed

NFR-SEC-005 The Solution shall provide the ability to identify certain information as confidential (e.g., PII, PHI, etc.) and only make that accessible by appropriately authorized users.

Proposed

NFR-SEC-006 When access to a user's account is restricted, the Solution shall provide a means for appropriately authorized users to "break the glass" and obtain access for emergency situations, as defined by Ohio policy.

Proposed

NFR-SEC-007 The Solution shall enforce the most restrictive set of rights/privileges or accesses needed by users/groups or processes acting on behalf of users, for the performance of specified tasks.

Proposed

NFR-SEC-008 The Solution shall provide the ability for authorized administrators to assign restrictions or privileges to ProposedState of Ohio Department of Administrative Services, Office of Information TechnologySupplement 1-Enterprise MDM Requirements, System Development Methodology and Staffing Requirements RFP 0A1213 Page 39



Statususers/groups.

NFR-SEC-009 The Solution shall support removal of a user s privileges without deleting the user from the Solution to ensure history of user's identity and actions.

Proposed

NFR-SEC-010 The Solution shall implement security controls in accordance with all Federal and State security policy and regulations. Compliance with the most current version of NIST 800-53 shall be documented as part of this NFR.(Refer to Supplement 2 for additional details)

Proposed

NFR-SEC-011 The Solution shall provide the ability to operate within an RBAC infrastructure conforming to ANSI INCITS 359-2004, American National Standard for Information Technology Role Based Access Control.

Proposed

NFR-SEC-012 The Solution shall provide more-advanced session management abilities such as prevention of duplicate logins, remote logout and location-specific session timeouts.

Proposed

NFR-SEC-013 The Solution shall provide the ability for concurrent users to simultaneously view the same record, documentation and/or template.

Proposed

NFR-SEC-014 The Solution shall provide protection to maintain the integrity of data during concurrent access. Proposed

NFR-SEC-015 The software used to install and update the system, independent of the mode or method of conveyance, shall be certified free of malevolent software (malware). Contractor may self-certify compliance with this standard through procedures that make use of commercial malware scanning software.

Proposed

NFR-SEC-016 The Solution shall provide the ability to perform Solution administration functions such as reference table maintenance and adding / removing users from the system.

Proposed

NFR-SEC-017 Information security shall be built into the Solution from its inception rather than bolted on after the Enterprise MDM Solution has been implemented.

Proposed

NFR-SEC-018 The Solution shall support security at the object level (e.g., Table, View, Index). Proposed

NFR-SEC-019 The Solution shall support security at the row and column level. Proposed

Offeror Response

NFR-SOA Service-Oriented Architecture (SOA)

NFR-SOA-001 The Solution components shall be committed to an advanced approach to interoperability using web services and Service Oriented Architecture (SOA) aligned with State standards and vision for interoperability.

Proposed

NFR-SOA-002 The Solution shall develop/integrate services using standardized Web Services formats. Proposed

NFR-SOA-003 The Solution shall allow for centralized service maintenance (new, update, delete). Proposed

NFR-SOA-004 The solution shall provide the ability to publish services and related data to be used by different types and classes of service consumers.

Proposed

Offeror Response

NFR-SDD Solution Design, Development and Customization

NFR-SDD-001 The Contractor shall repeat the test lifecycle when a failure occurs at any stage of testing (e.g., a failure in Acceptance Testing that necessitates a code change will require the component to go back through Unit Testing, Integration Testing, and so forth).

Proposed

NFR-SDD-002 The Contractor shall allow the State to run validation and testing software against externally facing Internet applications to help identify potential security issues, and must agree to repair any deficiencies found during this testing.

Proposed

NFR-SDD-003 As Enterprise MDM events contain date and time-sensitive elements, the testing infrastructure must provide a method of altering and synchronizing the Solution date throughout each test phase. This requires the

Proposed




Statusability to change the Solution date and time in some scenarios.

NFR-SDD-004 The Contractor shall install and test a single Defect Resolution Tracking Solution that the Contractor and the State shall use collaboratively for the tracking of Solution defects, security, and Solution issues.

Proposed

NFR-SDD-005 The Contractor shall provide the State access to the software components and documentation. Proposed

NFR-SDD-006 The Contractor may not use the State Production Solution resources (data or source files), or data derived from the production Solution resources, off-site without authorization from the State.

Proposed

Offeror Response

NFR-SA Solution Administration

NFR-SA-001 The Solution shall provide data archiving capabilities based on State defined criteria. Proposed

NFR-SA-002 All Solution communications shall be protected by at least 128-bit encryption. Proposed

NFR-SA-003 The Solution shall be supported by public key/private key encryption Secure Socket Layer (SSL) certificates.(Please refer to current State of Ohio Encryption Standards ITS-SEC-01 and FIPS 140-2. Links are provided in Supplement 2).

Proposed

NFR-SA-004 The Solution shall provide single sign-on capability and integrate with Ohio's Active Directory authentication and authorization.

Proposed

NFR-SA-005 The solution shall provide the capability to move all unnecessary data to offline storage according to a set of business rules and schedule to be defined by the County leadership as a part of the ongoing system operational decision making.

Proposed

NFR-SA-006 The Solution shall maintain collaboration records in line with all State retention policies. Proposed

NFR-SA-007 The Solution shall provide an auto archive/purge of the log files to prevent uncontrolled growth of the log and historical records storage using administrator-set parameters.

Proposed

NFR-SA-008 The Solution shall support encrypting data while in-transit and while at rest. Proposed

Offeror Response



Status

NFR-SM Solution Management

NFR-SM-001 The solution shall provide the ability to generate administrative alerts and warnings when statistics indicate an impact or potential limits on solution component performance and availability. The specific alerts will be defined by the hosting services provider.

Proposed

NFR-SM-002 The Solution shall provide Application Performance Monitoring and Management capabilities (i.e. transaction monitoring, synthetic transactions, component root cause analysis (e.g., Application Server Management).

Proposed

Offeror Response




Status

NFR-TML Transaction Monitoring & Logging

NFR-TML-001 The Solution shall allow for Report generation and analysis for application troubleshooting and capacity planning.

Proposed

Offeror Response

NFR-CP Capacity Planning

NFR-CP-001 The Contractor shall analyze, evaluate and plan for the Enterprise MDM system’s Capacity Utilization in the following areas:

CPU capacity Disk Space capacity Memory capacity and usage Data Center LAN and Wide Area connectivity elements capacity.

Proposed

NFR-CP-002 The Contractor shall provide a remediation/enhancement plan to the State, to address Enterprise MDM system exceeding the norms of the State as notified by the OIT in the following areas:

CPU aggregate sustained utilization capacity Disk space capacity Memory usage Data Center LAN and Wide Area connectivity elements capacity

Proposed

Offeror Response

NFR-USB Usability

NFR-USB-001 The Solution will adhere to the accessibility standard as outlined in the web guidelines and based on the W3C level 2 accessibility guidelines:(http://www.w3.org/TR/WCAG10/full-checklist.html).

Proposed

NFR-USB-002 The Solution shall support undo and redo while complying with specific rules like once confirmed/sent/etc., no undo/redo.

Proposed

NFR-USB-003 The Solution shall follow standardized conventions and limit the use of words, situations, or actions that have multiple meanings.

Proposed

NFR-USB-004 The Solution shall eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Proposed

NFR-USB-005 The Solution shall provide the option to have rollover / tooltip help or context messages and provide the option to turn off this option in the user preferences profile.

Proposed

NFR-USB-006 The Solution shall provide all Solution instructions in a visible or easily retrievable location, when appropriate.

Proposed

NFR-USB-007 The Solution shall adhere to all Federal and Ohio accessibility requirements, or their successors:(section 508 of the Rehabilitation Act and detailed in section 1194.22 of the Code of Federal Regulations, Web-based intranet and internet information and applications;http://das.ohio.gov/LinkClick.aspx?fileticket=99cw1kez4Hc%3d)

Proposed




Status NFR-USB-008 The solution's error messages shall be expressed in plain language, precisely indicate the problem, and

constructively suggest a solution.Proposed

NFR-USB-009 The Solution shall use colors to enhance user experience and Solution usability while complying with all disability requirements notated elsewhere in these requirements.

Proposed

NFR-USB-010 The Solution shall not show fields not accessible to a given user based on access rights, nor shall the Solution show fields not in use.

Proposed

NFR-USB-011 The solution shall provide validation checks by methods described within policy, functional, and detailed requirements.

Proposed

NFR-USB-012 The Solution shall identify invalid entries to the user as immediately as possible. Proposed

NFR-USB-013 The Solution shall provide the ability to suggest or automatically change entries that do not conform to data entry standards.

Proposed

NFR-USB-014 The Solution shall be designed to include only the necessary information and functionality on screens and shall be based on the user's access level and the user's configuration.

Proposed

NFR-USB-015 The Solution shall be designed to include logical transitions between screens and level of detail during navigation.

Proposed

NFR-USB-016 The Solution shall provide templates for data entry with identified mandatory and optional data fields. Proposed

NFR-USB-017 The Solution shall highlight and flag required and incomplete data fields. Proposed

NFR-USB-018 The Solution shall provide a user interface that shall be simple and consistent throughout all areas and functions of the solution.

Proposed

NFR-USB-019 The Solution's web interface shall be Web 2.0 compliant Proposed

NFR-USB-020 The solution shall support multi-language Proposed

NFR-USB-021 The solution shall support (including but not limited to; render and execute properly) the current or two immediately previous major versions (read major versions as: numbered versions prior to decimal [i.e., 9.x, 14.x, etc.]) of Internet Explorer, Firefox, Chrome, Safari, as well as native browsers on Android and IOS devices.

Proposed

NFR-USB-022 The solution shall preserve context by limiting abrupt transitions and redisplays to maximize and enhance the user experience and solution usability.

Proposed

NFR-USB-023 The Solution shall follow State of Ohio conventions, making information appear in a natural and logical order. Proposed

Offeror Response


3.9 RFP Assumptions

Assumption ID

Assumption Description

1 It is expected that upstream and target systems will be responsible for design, development and implementation of changes within their systems to support integration with the Enterprise MDM environment.

2 It is expected that Data Use Agreements, or MOU (memorandums of understanding) will be required.

3 It is expected that the list of data elements will be further validated by the Contractor.

4 During the Fixed-bid implementation phase, the Contractor will perform work that is documented and explicitly approved, which requires a written request that includes the scope, timing, applicable deliverables and cost is presented to and approved by the State.

5 The State has procured an enterprise license for Informatica MDM, which has sufficient licensing to support any design and data requirements within the scope of this RFP.

4.0 State Project Delivery, Management, Methodology and Approach Requirements

The Offeror will provide the State its recommended methodology and approach to the projects and any projects that arise following the successful completion of the project because of this RFP.

The State maintains a project management and reporting methodology 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 the overall project is delivered to the State as contracted. Therefore, a minimum standard 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. For purposes of this RFP, this minimum standard has been extended to include current environment assessment as well as data governance and stewardship related activities and deliverables that are specific to a master data management project.

The Offeror must provide a summary Project Plan as requested by the State. For purposes of a summary project plan specific phase and gate dates, effort and costs are a sufficient minimum.

Following the award of this Contract, and during the project mobilization phase Contractors must include the following deliverables and milestones within their detailed project plans and methodologies at a minimum upon commencement of the project: The Contractor will provide the State its recommended methodology and approach to the projects and any projects that arise following the successful completion of the project because of this RFP.



4.1 Project Management and Coordination ServicesThe Contractor will follow the Project Governance structure defined by the State. Project Management will include the activities to manage the Project including directing the Project Team according to the Project work plan, reporting status, managing issues, assessing quality, leading project meetings, and monitoring schedule and scope changes. The Project Team will produce project status reports on a weekly basis. The format of the status report will be mutually agreed to by the State and the Contractor during the first week of the Project.

The Contractor will, in conjunction with an authorized Statement of Work arising from this Supplement:

Be responsible for the coordination and delivery of the overall Project

Ensure that an appropriate “Project Kickoff” occurs and that all integrated work plans are agreed to by the State from project commencement

Ensure that all efforts have an effective version control mechanism for all documents within the project document library that will be maintained on a State provided Microsoft SharePoint site

Work with the State leadership to ensure that the Project is staffed appropriately

Ensure that required testing activities across both technical and operational components are completed to minimize Project risk

Collaborate with the task areas to ensure appropriate cross-team communication and delivery

For purposes of the Project, “Perform” means, that the party assigned the task has the duty and ultimate responsibility to take all appropriate steps to complete or facilitate the identified task unless otherwise provided for between the parties, subject to the Supporting party completing its interdependent responsibilities. The term, “Support” means that the party has the duty and responsibility to provide ancillary support or assistance, which may be necessary to enable the party providing the “Perform” task to complete that task unless otherwise provided for by the parties. The designation, “-” means that the party has no responsibility for the task, unless otherwise agreed by the parties.

Key Tasks State ContractorConduct Project kick-off meeting Support PerformCreate a Work Breakdown Structure (WBS) Support PerformCreate and Maintain a project work plan and any related deliverable sub plans Support PerformReview Deliverables and manage the State’s approvals Perform SupportReview Deliverables and manage the Contractor’s approvals Support PerformPrepare and conduct project meetings Support PerformPrepare and conduct stakeholder meetings Perform SupportCreate Project Status Reports adhering to the PMO policies Support PerformReport and manage issues and risks Support PerformMonitor and report schedule and scope changes Support PerformIdentify State stakeholders and manage expectations Perform SupportAssist with on-boarding for the Contractor resources Support PerformAssist with on-boarding for the State resources Perform SupportConfirm State Project staffing Perform SupportConfirm Contractor Project staffing Support PerformConfirm Project governance Perform SupportConfirm Data Governance Strategy and Framework Perform SupportInitiate System Turnover Process Support PerformPAC – Provide planned checkpoint review dates Support Perform


4.2 State Project Governance ConsiderationsThe State will provide the following team resources to participate in the overall governance of the project and its delivery:

Role Offi

ce o

f H

ealth

Tr

ansf

orm

ati

on Proj

ect T

eam

EDW

OD

M

Prov

ider

M

anag

emen

t

Ohi

o B

enef

its

JFS

Data StewardsKnowledge of the current business and data for Individual (Client, Recipient, Seeker, etc.) and Business (Provider, Payor, etc.) and in the position to identify and research data quality or other data related issues.

n/a Part Time SMEs

Part Time SMEs

Part Time SMEs

Part Time SMEs

Master Data Management StrategistKnowledge of the current master data management solutions and use of Informatica. Establishes direction from a data stewardship/governance as well as solution architecture and requirements perspective.

1 FTE

Business Analyst LeadKnowledge of Enterprise MDM functional, data and non-functional requirements to provide guidance to Contractor.

1 FTE

Data Analyst LeadKnowledge of Enterprise MDM data requirements and systems to provide guidance and oversight to the Contractor on data analysis related activities.

1 FTE

IT Specialist Knowledge of the source systems that supports the existing environments, data, and IT processes.

n/a Part Time SMEs

Part Time SMEs

Part Time SMEs

Part Time SMEs

Source Data Provider(s)Representation from participating agencies that collect the individual data elements and provide subject matter expertise to resolve questions.

n/a Part Time SMEs

Part Time SMEs

Part Time SMEs

Part Time SMEs

Project Leadership TeamProvide oversight and executive sponsorship to the Enterprise Master Data Management Effort.

1 PTE 3 PTE1 FTE

4.3 Create and Maintain Project PlanThe Contractor must produce a detailed Project Plan, in electronic and paper form, to the State Project for approval within twenty business days after the State issues a purchase order or other written payment obligation under the Contract.

Master Project Plan

The Project Plan should include the following (at a minimum):

Project Integration


Project Scope

Project Time

Project Quality

Project Staffing

Project Communications

Project Risks/Issues

Project Procurement

The Contractor must lead a planning session, which ensures the following:

A common understanding of the work plan has been established

A common vision of all deliverables has been established

Contains a critical path that identifies all major milestones, dependences (both internal and external to the project), resources by name and resource assignments and is complete and inclusive of the entire work effort from commencement until conclusion of all contracted activities

Clarity on scope of overall project and the responsibilities of the Contractor has been defined and agreed to by the State that includes a common understanding of the business, process, technical and other elements of the overall implementation as required

Thereafter, the Contractor must:

Formally update the Project Plan, including work breakdown structure and schedule, and provide the updated Project plan as part of its reporting requirements during the Project

Ensure the Project Plan allows adequate time and process for the development for the State’s review, commentary, and approval

The State will determine the number of business days it needs for such reviews and provide that information to the Contractor after award and early in the development of the Project Plan. Should the State reject the plan or associated deliverables, the Contractor must correct all deficiencies and resubmit it for the State’s review and approval until the State accepts the Deliverable at no additional cost to the State.

At a minimum, the Contractor must include a Proposed Project Plan(s), which will include the following:

A summary Work breakdown structure Scope statement that includes the Work objectives and the Work Deliverables and milestones associated with completion of all the Work with specific provisions for the work contained and as required by the projects

The Contractor must provide a detailed Project Plan as a Microsoft Project Gantt chart (in native MS Project file “.mpp” format), showing all major Work tasks on a week-by-week schedule, with Proposed Team Members (by name for Key Personnel and by Role for other Project team members) and indications of State participation requirements in the Project(s) to serve as the basis for managing and delivering the Work. The schedule must clearly demonstrate how the project will become fully operational by the delivery date. Within this detailed plan, the Contractor must give dates for when all Deliverables and milestones will be completed and start and finish dates for tasks. The Contractor also must identify and describe all risk factors associated with the forecasted schedule.


The Contractor will indicate who (State or Contractor) is assigned responsibility for each Deliverable within the work breakdown structure to the level at which control will be exercised

Performance measurement baselines for technical scope, budget adherence, deliverable assembly, production and approvals in the context of the overall schedule

Description of the Contractor’s proposed organization(s) and management structure responsible for fulfilling the Contract’s requirements and supporting the Work, in terms of oversight and control

A summary Required State staff and their expected roles, participation and level of effort by project area (e.g., functional, technical, business) as well as role within each Project Phase (e.g., Requirements, Design, Construction, Testing, Deployment)

Description of the review processes for each milestone and Deliverable (e.g., mandatory design review) and a description of how the parties will conduct communication and status review

Description of the Project issue resolution process including an escalation plan

Description of the approach to manage subcontractors effectively, if the Contractor is proposing subcontractors

4.4 Project Financial ManagementProject financial management is a discipline based upon standard financial and accounting principles focused on those principles that apply to effective management of project and data cleansing services. The primary focus of the project financial management with respect to this RFP is to ensure funding alignment between the fixed-not-to-exceed price contract with the Contractor for development and data cleansing services provided to the actual scope of services (e.g., components being supported along with other support tasks within the scope of this RFP) acquired and management of approved funds to be used for unanticipated project services. More specifically, financial management activities that the Contractor will be responsible for include:

Management of Unanticipated Project Services Funding Pool

Management of Data Cleansing Funding Pool

Management of project scope changes relative to the baselined project development and data cleansing services acquired as defined in this supplement

For purposes of this supplement and project development and data cleansing activities defined herein, the Contractor will be fully accountable for managing project development costs within the scope of the fixed-not-to-exceed price contract services acquired by the State as well as managing the funding pools for use to perform approved unanticipated project services and data cleansing activities.

With respect to managing costs associated with project development and delivery, the Contractor will be expected to perform monthly analysis of project development scope changes against the baselined requirements, deliverables and work products as defined in this supplement. This analysis will be reviewed monthly to determine whether adjustments to the project development fixed-not-to-exceed price contract are required to adjust it to reflect current scope, inclusive of all project change requests.

Unanticipated Project Services is newly proposed work for the Contractor’s application development team. Types of unanticipated work include additional work products or deliverables not contained in the RFP and associated SOW and enhancement requests. Following are the key process steps regarding how Unanticipated Project Services will be identified and managed:


Candidate unanticipated project services are identified through a project change request or email request from the State.

Candidate unanticipated project service request is documented using a Project Change Request form that provides additional descriptive information regarding the request, impact analysis, resource plan to resolve along with development, testing, and production deployment estimates. Resource costing performed on the Project Change Request is performed using the current blended project development rate in effect from the Contractor. If the request is for additional data cleansing services, then the Project Change Request is costed using the current blended rate for data cleansing resources.

The Project Change Request along with cross reference information to the inbound request information is documented in the Project Change Request Log.

The Project Change Request is routed to the Project Leadership Team and other key stakeholders for review and approval. Level of review and approval required will depend upon the nature and cost of the Project Change Request. Review and approval steps along with status of the Project Change Request are tracked in the Project Change Request Log.

Once the Project Change Request is approved, costs associated with the change request will be added to a committed column and used to decrement remaining available Unanticipated Project Services or Data Cleansing funds. If the Project Change Request is for a change in project scope, then the cost of the change request will be tracked with analysis on the fixed-not-to-exceed price contract.

Should the approved Project Change Request reduce the scope of project development performed that are a part of the project development fixed-not-to-exceed price contract, then the fixed-not-to-exceed price contract amount will be renegotiated to reflect this change.

Should the approved Project Change Request increase the scope of the project development performed that are a part of the project development fixed-not-to-exceed price contract, then the fixed-not-to-exceed price contract amount will be renegotiated to reflect this change.

The approved Project Change Request status is tracked through development, data cleansing, testing, and production deployment activities through to closure in the Project Change Request Log.

When the approved Project Change Request development is ready for production deployment (this doesn’t apply to data cleansing work) a Production Change Request is prepared, and approved using established release management processes.

Once the development work associated with the Project Change Request is deployed to the production environment and validated, the cost associated with the project change request is moved from the committed column to the actual incurred column (for unanticipated project services). The remaining available Unanticipated Project Services fund balance is decremented to reflect successful completion and deployment of the change. If the unanticipated project services work is design, architecture, or documentation related, then the cost associated with the project change request is moved from the committed column to the actual incurred column when the work is completed and has been formally accepted by the State.

For purposes of this Supplement and project development and data cleansing work contained herein, the Contractor will be responsible for the following key financial management tasks:

Key Tasks State ContractorDefine Project Services fixed price services contract service change management process Support PerformDefine Project Services Unanticipated Project Services and Data Cleansing fund management tracking and change management process. Support Perform


Key Tasks State ContractorPerform actual to forecast financial management of the project development and data cleansing services provided in the fixed-not-to-exceed price contract monthly. Support Perform

Perform monthly reporting of Unanticipated Project Services fund management including Project Change Requests in process and a detailed analysis of the remaining available funds Support Perform

Participate in financial management meetings with State Project Leadership team as well as other key State stakeholders Support Perform

4.5 Project Review Check Point Upon completion of the baselined Project Plan and on a quarterly basis throughout the Project, the Contractor, in conjunction with State Project team staff, must deliver a presentation to the State. At a minimum, the presentation must address any known State or Contractor issues or concerns, including but not limited to the following:

Project scope, budget and schedule

Any changes to Key named resources assigned to the Project

Project readiness including key issues and risk from their current status

Project Status including variance from baseline for key milestones, tasks, deliverables (Significant work products) and project closure

Methodology, approach, and tools to achieve the Project goals (inventory and status of completeness and agreement for documented project management and implementation approaches, i.e., Project management plan, communication plan, requirements traceability, implementation approach and methodology)

Roles, responsibilities, and team expectations

Upon completion of the presentation, the State will immediately assess the health of the project and determine next steps for moving forward with the Project, within one week of the meeting, which may include the following:

Continue the Project

Terminate the Contract

Suspend the Contract

See Suspension and Termination language in Attachment Four for remedies for failure to deliver the proposed work.

Note: There may be additional Project Reviews conducted by the State on an as needed basis throughout the term of the Contract to assess Project health and ensure the Project is progressing successfully.

4.6 Meeting Attendance and Reporting Requirements The Contractor’s project delivery approach must adhere to the following meeting and reporting requirements:

Immediate Reporting - The Project Manager or a designee must immediately report any Project staffing changes to the State Project Representative

Attend Weekly Status Meetings - The State and Contractor Project Managers and other Project team members must attend weekly status meetings with the Project Representative and other members of the Project teams deemed necessary to discuss Project issues. These weekly meetings must follow an agreed upon agenda and allow the Contractor and the State to discuss any issues that concern them.


Provide Weekly Status Reports - The Contractor must provide written status reports to the Project Representative at least one full business day before each weekly status meeting

At a minimum, weekly status reports must contain the items identified below:

Updated GANTT chart, along with a copy of the corresponding Project Plan files (i.e. MS Project) on electronic media acceptable to the State

Updated Critical Path analysis with the aforementioned GANTT chart and an accompanying PERT chart Status of currently planned tasks, specifically identifying tasks not on schedule and a resolution plan to

return to the planned schedule Issues encountered, proposed resolutions, and actual resolutions The results of any tests A problem tracking report must be attached Anticipated tasks to be completed in the next week Task and Deliverable status, with percentage of completion and time ahead or behind schedule for tasks

and milestones Proposed changes to the Project work breakdown structure and Project schedule, if any Planned absence of Contractor staff and the expected return date System integration/interface activities The Contractor's proposed format and level of detail for the status report is subject to the State’s approval

4.7 Utilize OIT’s Document Sharing/Collaboration CapabilityIn conjunction with the delivery of the Project, coincident with the start of the project through its conclusion, the Contractor must use the 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

Store all documents in machine readable, editable and native formats (e.g., XLSx, PPTx, VSD, DOCx) as opposed to proprietary, non-editable, image format or PDF based renderings

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

At the conclusion of the project, 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 is to remove all Contractor proprietary or non-State owned or licensed materials from the tool)


4.8 Production/Version Control and Release ManagementThe Contractor will be responsible for working with the State and executing the production deployment and roll-out of any Release Package to the State’s on-premises environment instance. Production deployment includes software deployment to the production environment and (if applicable) interfaces to production tools and systems that orchestrate, manage, report or control those devices and services managed by the Service, identification of interfaces and any required conversions/migrations, installation of server software, and any required testing to achieve the proper roll-out of the Release Package software.

Contractor will establish and comply with the State required implementation and deployment procedures. This may include laboratory testing, migration procedures, the use of any pre-production or pseudo-production environment prior to production migration. Contractor will submit to the State, for the State’s approval, a written deployment plan describing Contractor’s plan to manage each such implementation. The tasks and activities to be performed by Contractor as part of the deployment services also include the following:

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

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

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

If required, convert electronic data into a format to be used by the new solution using a data conversion program as well as perform any data cleansing of legacy data, with the State’s assistance, prior to loading data to the new solution

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

Compile and maintain solution issue lists

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

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

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


4.9 Maintaining Solution and Operations Documentation For all custom processes, modifications, and nonproprietary portions of the solution, the Contractor will:

Document the solutions developed or modified by the Contractor in accordance with established methods, processes, and procedures such that, at a minimum the State or a competent 3rd Party vendor can subsequently provide a similar scope of Services

Develop and maintain, as agreed appropriate, the documentation on system 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 will correct such documentation as part of normal day-to-day operational support

Update programmer, End User and operational reference materials

Maintain all documentation on the State’s SharePoint site

4.10 Project Delivery, Role and Responsibility Requirements The State has organized our requirements for responsibilities of the State and Contractor based on the anticipated Activity Areas required to analyze, design, implement and deploy the solution as well as those requirements and activities required to support the deployment of the overall solution. Should a Contractor, as a result of the review of these requirements in light of their proposed approach require additional roles or clarity, the Contractor must indicate the additional requirements of the State and provide a high level rational for the same as part of their response.

The responsibility matrices included throughout the remainder of this section identify Key Tasks to be performed as part of this project. Each Key Task has been assigned to a party and the level of responsibility for each party is designated as either a Perform, Support or designated “-” for no responsibility.

Note: If the Contractor’s recommended methodology does not align with the responsibility matrices below, the Contractor will propose and subsequently as the Contractor adhere to matrices that do align with the Contractor’s methodology. The Contractor must also demonstrate that the recommended methodology and the responsibility matrices comply with the State’s need to: (1) know the Contractor has a complete understanding of the State’s requirements, (2) the Contractor’s design and development efforts are in line with the State’s requirement for the solution, (3) monitor the Contractor’s progress during the project, (4) the project risk is acceptable and is managed effectively by the Contractor, (5) have accurate and complete technical documentation regarding the solution (as designed and as delivered), and (6) know the solution delivered and deployed by the Contractor has been adequately tested and meets the State’s requirements.

4.11 System/Environment Administration Support of the ProjectThe Contractor will coordinate with the State, but be responsible for all environments (production, non-production, demo/training/CRP, development and testing) as required to support the overall effort and will:

Perform technical activities including but not limited to: version control, PS-Admin, Informatica, PL/SQL, workflow, dashboard, reporting, batch integration, web service, notification and alert development, system code/object migrations, job scheduling definitions, patch implementations, log administration, data copies and exports, interface and scheduled reporting/ETLs, and responsibility for incident resolution such that migrations


into production will be executed at agreed periodic intervals and other production changes will be scheduled during the maintenance window

Support multiple release levels of System software/hardware elements for in-scope Services, provided that such support does not impair the Contractor’s ability to meet Contractor development and project commitments until such time as all environments can be upgraded to the same version/release level

4.12 Establish and Manage a Program Management & Master Release CalendarThe Contractor will coordinate with the State in the development, and maintenance on a monthly basis a Master Release Calendar that includes a schedule (with dates) of:

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

Implementation of Projects, Minor Enhancements or Discretionary Work

Scheduled Maintenance Windows and Planned Outages

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

Other pertinent dates that require end-user notification or coordination

4.13 Cooperation with State and State ContractorsContractor will cooperate with the State in its attempts at transferring, replacing or augmenting the services responsibilities to another provider in a manner in keeping with not adversely affecting the provision of ongoing services and other projects being performed concurrent with this project.

4.14 Requirements Confirmation and Analysis (for each release)The expectation for this project phase is the Contractor will thoroughly document the desired Enterprise Master Data Management business requirements, and elaborate on and confirm all State business, operational, functional and technical requirements and recommend changes which will improve the State’s business processes and requirements.

4.15 Current Environment AssessmentThe expectation for this project phase is the Contractor will thoroughly document the current Informatica platform environment focusing on its usage for the current state implementations of the Master Client Index (MCI) and Master Provider Index (MPI). Based upon this understanding, the Contractor will recommend a future state Master Data Management solution approach focused on both the business and data requirements as well as the optimal usage of Informatica platform components and services to achieve an Enterprise Master Data Management future state that supports both an Enterprise hub and potentially agency-specific hubs. Additionally, the focus will be on extending and improving MCI and MPI work performed for Ohio Benefits in a broader enterprise context.

4.16 Data Governance and StewardshipState of Ohio Department of Administrative Services, Office of Information TechnologySupplement 1-Enterprise MDM Requirements, System Development Methodology and Staffing Requirements RFP 0A1213 Page 55

The expectation for this project phase is the Contractor will collaborate with the State business and IT professionals to mature our current Data Governance and Data Stewardship practices. The matured set of practices shall include the following:

Strategy and Framework for Enterprise Data Governance

Strategies for Data Stewardship, Data Quality and Metadata Management

Data Management Standards to support the scope of the Enterprise Master Data Management initiative

Data Quality Policies, Standards, Procedures and Tools


Metadata Management Policies, Procedures and Guidelines

Identify and Define Master Data Management Key Performance Indicators

Define Master Data Management Dashboards and Reports

These strategies, policies, procedures, guidelines and tools will be used by the project team during each project implementation within the scope of this RFP. Scope of tasks coverage will include Enterprise MDM as well as Agency specific procedures and guidelines as they pertain to Individual and Business (Provider) data domains within the scope of this RFP. Contractor shall make recommendations on how these strategies, policies, procedures, guidelines, and tools may be extended for other ongoing projects and initiatives.

4.16.1 Agency Data Quality Improvement PlanIf an agency fails to produce data that meet required standards in any area, the Contractor must include a brief data quality improvement plan that describes how the agency must move toward quality standards to meet the delivery dates required by the Project. The plan must address all standards that the agency did not meet, describe what new policies or procedures to put in place to meet the standards, identify barriers to moving to a higher quality level, and identify the technical assistance needed to implement the plan.

4.17 Analyze Phase Requirements (for each planned release)The Contractor Team will review, analyze and update the State’s Requirements and system(s) documentation. The Contractor team will conduct workshops to confirm with SMEs the results of their business requirements analysis.

The Contractor Team will also analyze impacts to the integration points with external systems. In addition, the Contractor team will analyze external systems and data, and recommend data for migration to the solution as applicable.

The Contractor team will deliver the resulting business requirements (expected to be a modified version of the State’s current functional requirements), a Requirements Traceability Matrix (RTM), the accompanying business processes modified as required and a list of customizations if applicable. All changes to the State’s original functional requirements and business processes are to be clearly indicated.


Key Tasks State ContractorReview and update Business and Technical Requirements. Support PerformProfile source/target data and Document the results Support PerformDocument analysis of integration points with external systems. Support Perform Provide functional impacts within external systems. Support PerformAssess and Document impacts to upstream and downstream systems Support PerformCreate Requirements Traceability Matrix. Support PerformCreate Customization Tracking Database (if applicable). Support PerformDefine Functional and Technical Requirements. Support PerformDefine the solution architecture. Support PerformDefine changes within upstream and downstream system(s) Support PerformDocument possible solution options for identified gaps, as applicable Support PerformDocument plan for integration points. Support PerformDefine technical environment requirements for the project from design through deployment and run. This includes any components or tools required to support development, test, configuration management, etc.

Support Perform

Updated RTM with functional requirements and technical requirements cross-referenced. Support PerformDefine the required training and operations materials Support PerformDefine Data Quality Scorecard Support PerformDefine Data Quality Remediation Plan Support PerformPerform Data Profiling Support Perform

4.18 Design Phase Requirements (for each planned release)The Analyze Checkpoint must be successfully completed prior to beginning the Design 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 will also be completed at the Analyze Checkpoint.

The Contractor Team will create and maintain Functional Designs for the solution. Functional Designs contain data, business and security impacts and includes integration points to external systems.

Key Tasks State ContractorDefine or Extend Master Data Management Framework Support PerformDefine or Extend Infrastructure Architecture Perform (OIT) SupportDefine or Extend Business Architecture Support PerformDefine or Extend Data Architecture Support PerformDefine or Extend Integration Architecture Support PerformDefine or Extend Solution Architecture Support PerformCreate Functional Designs (High and Low level functional design documents) based on requirements. Support Perform

Define and Document Data Quality Rules Support PerformBuild changes within upstream and downstream system(s) Perform SupportUpdate Requirements Traceability Matrix with design and configuration cross references Support PerformCreate System Test, UAT, and ORT strategies Support PerformCreate and update the Technical Designs for solution, including any interfaces to external systems. Support Perform

Create and update the Security Designs for the solution. Support PerformUpdate environment plans for the Project Support PerformBuild technology environments required for Build & Test Support PerformSupport technical environments, including patches and fixes Support PerformCreate Implementation and Deployment Strategy Support PerformCreate the training and operational document outlines Support PerformDefine Development Playbook Support PerformPerform Data Profiling Support Perform


4.19 Build Phase Requirements (for each planned release)The Design Checkpoint must be successfully completed prior to beginning the Build 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 will also be completed at the Design Checkpoint.

The Contractor Team will build the solution and prepare for testing. The State will provide one (1) knowledgeable SME per functional area in test preparation and as mutually agreed to with the Contractor to support test preparation.

Key Tasks State ContractorProvide test conditions and scripts. Support PerformBuild and Unit Test configuration and security to support the business processes Support PerformBuild Data Quality Dashboard Support PerformCreate System Test, UAT, and ORT conditions, scripts, and scenarios Support PerformPrepare testing schedule and participation for System Test, UAT, and ORT Support PerformCreate Master Test Plan Support PerformBuild Data Quality Rules Engine and Data Quality Dashboards Support PerformTest changes within upstream and downstream system(s) Perform SupportBuild and Unit Test the solution as applicable Support PerformBuild and Unit Test customizations as applicable Support PerformPerform Manual Analysis and Cleansing of Source system data Support PerformBuild and Unit Test updates to Execution Environment (i.e. interfaces, print, security services, and network infrastructure) Support Perform

Build Test Environment(s) Support PerformBuild Training environment Support PerformBuild Operations Environment (i.e. production) Support PerformCreate Assembly Test and Performance Test conditions, scripts, and scenarios Support PerformSupport technical environments, including patches and fixes Support PerformCreate Deployment and Stabilization Plan and tools (readiness criteria, critical path, and cutover activity list). Support Perform

Create the training and operational documents Support PerformUpdate Requirements Traceability Matrix Support PerformPerform Data Profiling Support Perform

4.20 Test Phase Requirements (for each planned release)The 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 will also be completed at the Test Readiness Review Checkpoint.

For avoidance of doubt with respect to testing activities, the Contractor is accountable for all activities associated with System Test while the State will participate in these activities. The State is accountable for UAT Test execution while Contractor will be responsible for test preparation, management and tracking of UAT activities.

The Contractor Team will execute System Test, User Acceptance Test (“UAT”), and Operational Readiness Test (“ORT”). The State will provide SMEs knowledgeable in test execution and as mutually agreed to with the Contractor to support test execution.

System Test focuses on the customizations, configurations, workflow and integrations. Test conditions and test scenarios to be included in the System Test will 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.


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 Agency resources. A key objective of UAT is to facilitate an understanding of the technology and the business change being implemented.

ORT includes end-to-end testing of processes and technologies and will be executed by State members of the Project team. ORT will be conducted during a specific time-period before Go-Live.

The State will conduct a Security Test that includes an application scan, manual testing of the system using client-side code analysis, and loading maliciously formatted inbound interface files.

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

Key Tasks State ContractorDevelop and maintain test data repositories as agreed appropriate Support PerformManage and track System /Regression Test, UAT, and ORT Support PerformManage and execute Data Quality rules in Rules Engine and document results Support PerformValidate and Sign-off on Data Quality rules Perform SupportExecute System / Regression Test and document results Support PerformDeploy changes within upstream and downstream system(s) Support PerformExecute UAT Perform SupportDocument UAT results Support PerformExecute ORT Perform SupportDocument ORT results Support PerformPrepare for and execute Security Test Perform SupportPrepare for and execute Assembly Test Support PerformPrepare for and execute Performance Test Support PerformSupport Functional Team Testing Support PerformConduct Test Moves to Production (Mock Conversion) Support PerformCreate the Deployment and Stabilization Plan Support PerformDevelop, update and maintain a migration checklist Support PerformConduct training on operational processes and procedures to the users Support PerformPrepare for final Move to Production Support PerformUpdate Requirements Traceability Matrix Support PerformPerform Data Profiling Support Perform

The Contractor team will execute Assembly Test and Performance Test.

Assembly Test verifies that the technical architecture works together as planned and tests that all modules were migrated appropriately. The objective of the Assembly Test is to verify that related components function properly when assembled into an overall system.

Performance Test establishes a baseline of acceptable performance for a sample of master data transactions. The tests are conducted under a practical proportion of expected transaction and user volumes to mimic real-world usability. The sample is based upon mocked up data entered into the solution. The number, frequency, and concurrency of online user transaction load will be defined using the most recent Contractor team estimates of activity available at the time of test preparation. The estimates will be based on enterprise-wide usage (as opposed to usage of only the Initial Release Agencies).

The Contractor will recommend a Test Moves to Production strategy as appropriate for their solution’s environment(s). The Contractor will 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 bugs in an “in-scope” environment, supported server, or “in‐scope” software element licensed by a Third Party to the State, the Contractor will assist the State by referring such incident to the appropriate Third Party entity for resolution and coordinating with the Third-Party Contractor, as appropriate, to help minimize the State role in problem management.

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

4.20.1 Project Incident ManagementFor purposes of this Supplement, an incident is defined as an unplanned interruption in a development or test environment that is being used to perform application and IT service development. Incident management is the process utilized for managing these to resolution. Project Incidents may be recognized by the development team, detected and reported by event monitoring tools or communication from users involved in testing or data governance activities where their work involves use of the Informatica Platform. From a project perspective, objectives for this process include:

Ensure that standardized methods and procedures are used for efficient and prompt response, analysis, documentation and reporting of incidents

Increase visibility and communication of incidents to IT support staff

Utilize professional approach in quickly resolving and communicating incidents when they occur

The Contractor will be responsible for the following activities:

Define a project incident management approach and process for the development and test environments used for release development within the scope of this RFP

Recommend and implement tools to perform project incident management

Perform incident status tracking and reporting

4.20.2 Project Defect ManagementFrom a project perspective, defect management is the process by which identified functional and technical deficiencies in the release under development. Additionally, a project incident may be escalated to a defect if the incident occurred as a result of software changes introduced to a development or test environment by work performed by the project team. The three types of defects managed by the project development team include:

Development Defects - These are confirmed defects discovered in development or testing environment during related development, system, performance, assembly and UAT testing performed by the project team. Identified defects are reviewed and assigned a severity and priority that determines what order the defects are resolved. All severity 1 and 2 defects are resolved prior to the release under development being deployed to the production environment. The business users may also prioritize defects discovered during system, performance or UAT and indicate that the release under development may not be deployed to the production environment until these are successfully fixed and retested.


Warranty Support - These are confirmed defects discovered in the Production environment within the twelve (12) month warranty support period. Correction of the identified defect may occur within the warranty support period or slightly outside of the period consistent with established SLAs defined in Supplement 4 of this RFP. In most cases, correction of warranty support defects are performed by the application development team and deployed to production by the M&O team.

Infrastructure Configuration Changes – Upon analysis and triage of an incident or problem report, the project development team may discover that an Informatica platform or other configuration change is required to correct the problem and that no changes to an Informatica object or source component are required to resolve the problem. When this occurs, the change is treated as a configuration change and not a defect. These changes are performed by the project development team for the impacted development or testing environment or are coordinated with the State OIT team if the required change is to infrastructure not owned or maintained by the project development team.

Defect management processes and tools will leverage those tools and techniques used by the application development team. The Contractor is requested to provide recommendations regarding defect management tool usage as part of the RFP response. All defects will be associated with the specific release that introduced the unexpected behavior.

4.21 Deploy Phase Requirements (for each planned release)A Test Completion Checkpoint must be successfully completed prior to beginning the Deploy phase. This includes the State’s acceptance of all deliverables due to date per the project schedule.

The Contractor Team will support the deployment activities and will conduct a deployment readiness assessment to determine the readiness of the organization and the solution for go-live. Part of the readiness review will be to determine that the State has reviewed and accepted all functional, technical, and user documentation. Upon completion of the readiness assessment, the State will make a final go-live decision. The go-live date will be scheduled and resources, roles, and responsibilities will be confirmed.

Key Tasks State ContractorIdentify deployment readiness criteria, critical path, and contingency plan Support PerformAssess deployment readiness Support PerformDefine stabilization approach and plan Support PerformVerify Requirements Traceability Matrix Completeness Perform SupportPerform end user role-based security implementation design. Provide guidance and recommendations regarding best practices and methods based upon business requirements Support Perform

Define end user security mapping and assignments for new or altered functionality Perform SupportCreate production deployment plan Support PerformCreate detailed task lists and work plans for deployment Support PerformCreate production deployment staffing schedule Support PerformCreate production deployment roles and responsibilities Support PerformPerform Data Conversion/Migration and Remaining Data Cleansing Support PerformPerform deployment activities Support PerformPerform cutover activities Support PerformCreate Solution Run Book Support PerformSupport technical environments, including patches and fixes Support PerformCoordinate Production Acceptance Checklist items for Deployment Perform SupportDeploy the Solution Support PerformSystem Turnover Support Perform

The Contractor Team will drive the planning and execution for the system deployment activities. Deployment includes coordination of software deployment to the file server elements, identification of interfaces and any


required conversions/migrations, installation and testing of any required middleware products, installation of server software, and any required testing to achieve the proper roll‐out of the application software.

The Contractor Team will execute the deployment plan, which will describe the plan to manage the go-live. The tasks and activities to be performed include the following:

Execute required data conversions or migrations as applicable

Perform required data matching activities and error reporting as applicable

Document data issues and provide to the State for resolution as applicable

Compile and maintain solution issue lists

Produce an end-to-end final validation of the operational architecture and corresponding operational documentation for the upgraded and implemented modules

Conduct quality and progress reviews with appropriate State personnel

Develop, and thereafter maintain and make available to the State, a knowledge base of documentation gathered throughout the Project’s life and allow for re‐use of such within the State for future Project Phases or upgrades

Create solution run book

Transition solution support responsibility according to the Deployment & Stabilization Plan. This transition activity will include a series of solution support transition meetings and review of the solution run book

The production deployment schedule will be agreed upon mutually by the State and the Contractor.

Production migration activities will adhere to the State Production Acceptance Criteria (PAC) and will not be considered for production migration until all such criteria are met or otherwise accepted by the State. Any deviation, partial acceptance or waiver of requirements in the Production Acceptance Criteria must be agreed to in writing by the State in advance of presentation of any deliverables associated with, or determined to be part of these Production Acceptance Criteria.

Throughout the Project, Application and Tools patches and fixes will be reviewed. Patches will be applied until the QA environment is established. After the QA environment is established and prior to Go-Live, any Application or Tools related patches and fixes will be evaluated for implementation based on the criticality of the patch or fix.

4.22 Organization Change ManagementOrganization Change Management pertains to those activities and work products designed to assist the State with adoption of Data Governance, Data Stewardship, Data Quality, and Enterprise MDM solution utilization. As such, organization change management will cover those activities that require executive sponsorship and cross-agency participation to support the effective implementation of an Enterprise MDM solution along with a strategy that’s focused on helping individuals understand how to make the underlying process changes successfully.

While change happens one person at a time, processes and tools need to be developed to facilitate this change. More specifically, the State seeks assistance from the Contractor in the following areas:

Defining an Organization Change Vision

Creating an Organizational Change Sponsorship Roadmap


Creating and Executing an Organizational Change Strategy and Plan

Performing Organizational Change Analysis

Creating Organizational Change Communication Plans and Materials

Creating Organizational Change Job-Aids and Training Materials

Conducting Organizational Change training sessions.

The Contractor will perform or assist with the performance of the following:

Key Tasks State ContractorConduct Organization Change Vision Sessions Support PerformDefine an Organization Change Vision Support PerformCreate an Organizational Change Sponsorship Roadmap Support PerformSocialize Organization Change Vision and Sponsorship Roadmap with Key State Personnel Support PerformCreate an Organization Change Management Strategy Support PerformCreate an Organization Change Management Plan Support PerformPerform Organizational Change Analysis Support PerformCreate Organizational Change Specific Job-Aids and Training Materials Support PerformExecute the Organizational Change Management Plan Perform SupportConduct Organizational Change Training Sessions Support PerformMeasure Outcomes of Organizational Change Management activities and fine tune plan Support Perform

The Contractor will drive the planning, analysis and material development while the State will lead on the overall execution of the organizational change management plan.

4.23 Knowledge Transfer and Production Handoff (for each planned release) The Contractor will perform knowledge transfer support to the State in keeping with State System Turnover

process, which will be made available to the Contractor at the commencement of the project to support knowledge transfer to the State. In general, the System Turnover deliverable will include, at a minimum, the following work products:

Final Requirements Traceability Matrix for the Project as Implemented

A list of all customizations and objects as implemented

Detailed System Test Cases and Demonstration of Successful Completion of Same

Detailed Performance Testing Results showing at least one high volume process (e.g., a Fiscal Quarter or Year or Seasonal Processing as mutually agreed)

Completion of State User Acceptance Testing and an affirmation of same by State

Operational Readiness Testing Results and an affirmation of same by State

Complete User and System Administration Documentation that represent the system as implemented

Complete training and knowledge transfer to all Enterprise MDM users, upstream and downstream system stakeholders

Complete operational documentation sufficient for the State or the State’s managed service vendor to operate and maintain the system in the State’s environments inclusive of Production, DR, Demo/Train and at least one non-Production replica of the system as delivered


Complete the Production Acceptance Checklist and conduct review meetings with the State Project Manager and other State personnel as described in the System Turnover process

4.24 Project Completion Activities, Final Documentation and Post Implementation Support Obligations

The warranty support period for each production release defined as a part of this RFP will be 12 months from the production deployment date. If after ninety (90) days of successful execution (defined as no Severity 1 or 2 issues) by the Contractor in the State production environment, the Contractor shall be relieved of active management of the release as contained herein. During the period, immediately following the introduction of the Contractor provided enhancements, configurations or extensions to the State’s production environment the Contractor must:

Ensure adequate staffing from the Contractor Project Team is on hand (or available remotely) to ensure that during this period all defects identified by the State and mutually committed to resolve by the Contractor in this RFP or under any SOW are adhered to.

This responsibility shall specifically include:

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 system performance prior to the implementation of Contractor developed elements

All interfaces, and system functions perform and function as specified

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

Obtain a final acceptance document from the State and the Contractor confirming that all the above has been delivered and accepted as final

If, during the warranty support period, the introduction to Production, a Severity 1 or 2 issue occurs that can be directly attributable to the efforts of the Contractor, and not the State or other non-Project parties, the change will be made within established SLAs as defined in Supplement 4.

4.25 Future Project Services Pricing Response and Rate CardContractors must provide a Project Rate Card, by project personnel role and experience level as well as Technical role and experience level that is binding over the Contract term. Additionally, the Contractor is requested to provide two blended rates. The first is a blended rate to be applied when estimating Project Change Requests for project scope changes and Unanticipated Project Services. The second is a blended rate to be applied when estimating Project Change Requests for additional data cleansing services These blended rates along with the resource staffing that used as the basis of estimate when calculating each blended rate needs to be provided as a part of the response to this RFP. The Contractor may not propose rates (blended or otherwise) in any Project Service SOW that differs from these rate cards as allowed under any contract arising from this RFP.

5.0 Schedule of Deliverables and Work Products State of Ohio Department of Administrative Services, Office of Information TechnologySupplement 1-Enterprise MDM Requirements, System Development Methodology and Staffing Requirements RFP 0A1213 Page 64

To support the execution of the Project and provide supporting follow-on documentation, the Contractor will create and deliver to the State the following set of Deliverables, Work Products and Artifacts. The State Project Manager will serve as the representative for coordinating respective internal reviews of the subject Deliverable(s) and Work Products for sign off by the State. The Contractor should modify or propose other deliverables based on their solution or methodology characteristics. Any differences proposed to the ones listed below should include an explanation in the Contractor’s response.

5.1 Delivery and Deliverable Standards The Offeror will define, document and submit all standards they intend to utilize in the performance of this

project. Once the State approves these standards, variances to standards must be approved by the State prior to implementation of other than standard practices.

The Contractor’s work and deliverables will be in accordance with the Contractor’s standards (e.g., SDLC, project management, etc.) that have been approved by the State

5.2 Schedule of Deliverables and Work Products

Artifact, Work

Product or Deliverable #

Name Work Product and Deliverable Descriptions Phase

WP-001 Project Execution Methodology

This is a detailed description of their requirements gathering and analysis, design, build, test, deploy and run methodologies the Contractor follows, standards the Contractor intends to apply to this project, and any applicable tool sets. Contractor must address topics such as:Resource ManagementConfiguration ManagementData ManagementOrganization Change ManagementDevelopment MethodologyTest MethodologyTraining

Prioritization and Scheduling

WP-002 Project Work Plan Documents the tasks required to complete the Project, the responsible party for the task, task dependencies, and the resources, duration and work hours required. This plan should include key milestones and phases. The project work plan should be in an acceptable format for the State (e.g., MS Project). The Contractor’s project manager will work with the State’s project manager to ensure an acceptable Project Workplan is completed and accepted as baseline within 20 business days after the Kickoff Meeting.


WP-003 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 presented and maintained over the course of the project to track the earned value against the proposed costs and work efforts. This WBS will be reflected in the Project Workplan.


WP-004 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, Administrator, Security Analyst, Database Administrator, or any other roles deemed necessary by the Contractor. The Contractor will specify the percent of time each resource will perform their role on State premises.



Artifact, Work



WP-005 Organization Structure This is an org structure reflecting a high-level org structure that incorporates both Contractor and State resources. Roles to address may include any of the following:

Sponsors and Stakeholders Project Management Quality Assurance Team Structure and Leads


WP-006 Phasing Strategy/ Deliverables by Phase

Documents the recommended phasing strategy and deliverables by project phase for each project or release in the scope of this RFP.


WP-007 Detailed Cost/Time Analysis

Financial analysis of costs associated with completing the individual project within the scope of this RFP along with the time analysis as documented in the project plan.


WP-008 Project Management Plan This document must explain the approaches used for the following: Scope Management Change Management (including required communications,

escalation path and approvals) Issue Management Risk Management Communication Management Stakeholder Management Status Reporting Project Workplan Management Project SLAs, SLOs, and Metric Reporting Project Budget /Actual Analysis


WP-009 Requirements Management Plan

This document explains the approaches and techniques used to elicit requirements, document requirements and obtain business and technical approval of the requirements. This document also contains specifics regarding how requirements management tools will be used to document requirements as well as how the requirements traceability matrix will be generated ad maintained.


WP-010 Project Charter A statement of the scope, outlines the project objectives, constraints, key business drivers and benefits, reviews major items that are in and out of scope, identifies the main stakeholders, discusses major business and technical risks that may be encountered during project execution, proposed budget and spend authority, high level project release planning and key milestone dates, and defines the authority of the project manager. It provides a preliminary delineation of roles and responsibilities of those involved in the project. The project charter also serves as a reference of authority and focal point throughout the project. It represents a baseline for the overall project definition and may be used in both team meetings and in change management discussions to assist with scope management. This deliverable also contains the Project Management Plan and Requirements Management Plan work products.


WP-011 Kickoff Meeting Deck Documents the governance for the Project, roles, approach, timeline, and deliverables in a presentation format to be presented to the Project team.


DEL-001 Project Plan, Charter & Kick-Off Package

Contains all planning work products including Project Execution Methodology, Project Work Plan and Work Breakdown Structure (WBS), Resource Plan, Organization Structure, Phasing Strategy and Deliverables by Phase, Detailed Cost and Time Analysis, Project Management Plan, Requirements Management Plan, Project Charter, and Project Kick-Off meeting deck and supporting materials.


WP-012 Current Technical Environment Document

Evaluates the current infrastructure, technologies, versions and configuration specifics that are in used for the currently deployed and upon which existing Master Client Index (MCI) and Master Provider Index (MPI) solutions are implemented.

Current Environment Assessment

WP-013 Current MCI Documents and evaluates the current MCI implementation and identifies opportunities for improvement.

Current


Artifact, Work



Implementation Assessment

Environment Assessment

WP-014 Current MPI Implementation Assessment

Documents and evaluates the current MPI implementation and identifies opportunities for improvement.


WP-015 Future State MDM Solution Recommendations

Documents future state MDM framework and solution architecture alternatives and recommends solution(s) for the State to consider with the implementation projects within the scope of this RFP.


DEL-002 Current Environment Architectural Assessment

Contains all current environment assessment work products including Current Technical Environment (Informatica Platform) document, Current MCI Implementation Assessment, Current MPI Implementation Assessment, and Future State Enterprise MDM Solution Recommendations.


WP-016 MDM Key Performance Indicators

This document defines master data management related key performance indicators and their calculations that were identified as part of the data stewardship strategy work performed. These definitions will be used to implement master data management related dashboards and reports.

Data Management

WP-017 MDM Dashboards and Reports

This document defines requirements and functional design for dashboards and reports to be generated and used for MDM development and MDM operational management.

Data Management

DEL-003 Data Governance Strategy and Framework

This document defines the Data Governance Strategy and Framework to be used in managing the data domains within this scope of this RFP. The framework will be defined in such a manner that it can be readily extended for other data domains in the future. This strategy and framework shall describe (at a minimum):

Data Governance Charter, Vision and Mission Statement Data Governance Organization Structure, Roles and

Responsibilities Data Governance Goals, Governance Metrics, Success

Measures and Funding Strategies Data Governance Intake Process Proactive, Reactive and Ongoing Data Governance Processes Decision Rights, Accountabilities and Controls Data Governance Maturity Model and Roadmap Participation and Integration points with project development

teams Monitoring and Reporting processes Privacy, Security, and Regulatory Compliance Approach and

Coordination

Data Management

WP-018 Metadata Management Policies, Procedures & Guidelines

These documents define processes and procedures to be followed to request, review and approve changes to the Business and Technical metadata to ensure accuracy. These processes and procedures will support both real-time and batch data changes. Procedures will also be developed that provide step-by-step instructions on how to export data from either the Informatica Business Glossary or Metadata Manager and distribute to others for review.

Data Management

DEL-004 Metadata Management Strategy and Approach

This document defines a strategy that ensures that Business Glossary and Metadata Manager are updated with Source and Target “current state” and “future state” business and technical metadata.

Data Management

WP-019 Data Quality Policies, Standards, Procedures, and Tools

These documents define discrete data quality policies and procedures that further elaborate the data quality management strategy transforming strategic concepts into actionable steps that the data stewards may use (or direct others to use) to resolve identified data quality issues. This work product also includes tools that may be used to either automate or make the data profiling and related analysis work easier to perform.

Data Management


Artifact, Work



WP-020 Data Cleansing Approach and Tools

This document defines data cleansing approaches to be used on the project and tools that will be developed or leveraged as part of data cleansing effort.

Data Management

DEL-005 Data Quality Management Strategy and Approach

This document will define a strategy that ensure the quality and integrity of data loaded into the Enterprise MDM architecture and establish a plan/approach to proactively monitor the data once it is loaded. More specifically this strategy will outline:

Summarize results of data profiling efforts to analyze and make recommendations for global data standards, match rules, merge rules, and unmerge rules.

Define approach for developing a reusable data quality rules engine to automate data standardization and cleansing.

Define approach to identify and document data quality issues and approach to be used to establish and execute a quality remediation plan for both impacted source systems and the Enterprise MDM.

Define approach to identify missing data and establish a data enrichment plan by the assigned data steward.

Data Management

WP-021 Functional Requirements Define and further elaborate the State’s original functional and data requirements and the rationale for changes to these. These requirements should be to a level of detail such that ambiguity is removed and that they support the development of functional and technical specifications. The data requirements are also captured in a Business Glossary.

Analyze

WP-022 Technical Requirements All recommended changes to the State’s original technical requirements and rationale for the changes. These requirements should be elaborated upon as required to support the development of the technical specification and design.

Analyze

WP-023 Data Requirements/ Business Glossary

Data requirements are those data elements that correctly represent the data domain within the scope of the project. When elaborating data requirements, the logical organization and relationships between data entities and attributes are analyzed. Additionally, business relevant to data capture and transformation are also identified. Data requirements are a prerequisite to measure data quality. From a business perspective, data requirements are captured in a business glossary that’s used to communicate and govern the organization’s business concepts, terminology, definitions, and relationships between terms (glossary data elements).

Analyze

WP-024 Non-Functional Requirements

A requirement that specifies criteria that can be used to judge the operation of a system, or a quality attribute of the system rather than specific behaviors.

Analyze

WP-025 Non-Functional Requirements Assessment

Review and evaluate the State’s original non-functional requirements and make recommendations for changes and/or perform additional elaboration of these requirements to fully define quality and other measurement considerations.

Analyze

WP-026 Business Rule Definition A rule that defines, describes or constrains some aspect of business operational processes or data and always resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business. These rules may apply to people, processes, corporate behavior and computing systems in an organization, and are put in place to help the organization achieve its goals.

Analyze

WP-027 Data Quality Scorecard Requirements

This document defines requirements and high-level design for a data quality scorecard. The scorecard will be used to manage overall data quality of the data domain within scope of the project.

Analyze

WP-028 Report Requirements Necessary information required by a department, organization, or governmental body that is organized in a specific format and generated either on-demand or within a certain period of time to a defined schedule. Data contained in these reports are captured as data requirements.

Analyze


Artifact, Work



WP-029 Process Flows Illustrate and document future state business process flows, highlighting both user interaction by role and key integration points as well as internal controls.

Analyze

WP-030 Process Change Model This document identifies business processes impacted by the data domain and State Agencies within the scope of the project and how these processes may be changed or enhanced to improve overall data quality and confidence levels in the future state solution in scope.

Analyze

WP-031 Business Process Definition

This document defines new, future state business processes that will be implemented either within the scope of the project or in parallel with the project.

Analyze

WP-032 Requirement and Process Verification

Documents the results of the requirement and business process analysis and workshop sessions in spreadsheet format, specifically:All recommended changes to the State’s original functional requirements and State processes and rationale for the changes.For each business process gap analyzed, list the functional requirement, standard functionality of the appropriate component of the solution, options to meet the requirement and recommendation

Analyze

WP-033 Requirements Traceability Matrix

Lists the requirements for the processes which will be designed and/or built and subsequently tested and deployed. This deliverable will be revised and updated and will be due at each phase check point or as defined in the agreed upon project work plan.

Analyze & Updated at end of each subsequent phase

DEL-006 Requirements Definition This document is a compilation of the following documents or work products:

Functional Requirements Technical Requirements Data Requirements Non-Functional Requirements Non-Functional Requirement Assessment Business Rule Definitions Data Quality Scorecard Requirements Report Requirements Process Flows Process Change Model Business Process Definition Requirements and Process Verification Requirements Traceability Matrix

Analyze

WP-034 Level 0 System Design This document defines the level zero context data flow diagram (DFD) with system and descriptive information regarding each integration point contained within the diagram.

Analyze

WP-035 Solution Architecture Implementation Roadmap

This document and supporting charts define a roadmap of the project for the data domains and agencies within its scope.

Analyze

WP-036 MDM Architecture Framework

Documents the architectural design of the MDM framework to be implemented to support the data domains within the scope of the project.

Analyze

WP-037 Business Architecture This document defines the blueprint of the Enterprise MDM solution project to provide a common understanding of the State and agencies within scope. Aligns strategic objectives of the initiative to tactical data domain management and governance. Additional artifacts incorporated in this document include Business Process Model, Class Models, and Use Case Models.

Analyze

WP-038 Logical Infrastructure Architecture

This document and associated diagrams defines the future state logical infrastructure landscape comprised of hardware, software, and infrastructure component relationships and primary end-to-end data flow between the respective components. The analysis contained in this

Analyze


Artifact, Work



document supports functional, data, technical and non-functional requirements as well as MDM Architectural Framework considerations.

WP-039 Logical Data Architecture This document and its supporting logical data models and related artifacts defines the target data architecture that enables the defined business architecture and architectural vision. It also identifies candidate architecture roadmap components based upon gaps between the baseline and target data architectures. Additionally, the data architecture defines:

How data entities are utilized by business functions, processes and services

How and where enterprise data entities are created, stored, transported and reported

Data transformations and complexity to support information exchange between applications

Supporting data integration requirements Data definitions, models, and other related metadata

Analyze

WP-040 Logical Integration Architecture

This document defines the logical integration architecture and associated artifacts which elaborates the integration approaches, methods, techniques, and communication protocols to ensure that data moves from one application to another. May also specify or design common component development, templates, and code snippets to consistently implement data integration between the Enterprise MDM data hub or supporting hub and the agency specific applications that utilize the data.

Analyze

WP-041 Logical Enterprise Architecture

Update logical enterprise architecture diagrams to reflect changes covered under other solution and architecture design documents that are within the scope of this RFP.

Analyze

DEL-007 Solution Architecture This document defines the application architecture that is to be used during the project and contains the solution architecture (logical and physical). This architecture must show all components and how various systems interrelate, including the external technical environment the solution will operate within.

Analyze

DEL-008 Data Quality Remediation Plan

This document defines data domain specific remediation activities and approaches to be used during the project. This plan leverages and expands upon data quality strategy, policies, procedures, and guidelines defined from an overall data management perspective.

Analyze

WP-042 Implementation Strategy This document defines the implementation strategy and approach specific to the data domains within the scope of the individual project or release.

Analyze

WP-043 Deployment Strategy This document defines the deployment strategy and approach that will be used to perform data cleansing and conversion as well as cover other summary level deployment considerations.

Analyze

WP-044 Knowledge Transfer Plan A plan defining the activities and roles required to perform knowledge transfer of the operations and support of the solution.

Analyze

DEL-009 Implementation & Deployment Strategy

Consolidation of Implementation and Deployment Strategies and approaches that will be used to perform data cleansing and conversion as well as to implement the data domain artifacts under development for a specific release. This deliverable also includes planned knowledge transfer activities that will be deployed as part of the software implementation and data conversion process.

Analyze

WP-045 Technical Environments Requirements

The identification of all technical environments and the associated requirements, inclusive of all technical environments to be used for the project from the Build Phase through Test, Deploy and Run.

Analyze


Artifact, Work



WP-046 Infrastructure Migration Plan

Identifies the activities and tasks to be executed to complete migration of MDM infrastructure to the new set of target development and testing environments. This deliverable also defines the configuration and use of each environment and product within the Informatica platform and also incorporates the Technical Environments Requirements work product.

Anayze

WP-047 Performance Requirements Defines performance requirements for the solution under design. These requirements are usually defined as a part of the capacity planning process that’s performed during the design phase of the project. At a minimum, performance requirements include the following:

Maximum satisfactory response time for each distinct type of user-computer interaction or system-to-system interaction either through batch processing or web services during peak processing periods.

Response time that’s minimally acceptable the rest of the time. Typical throughput required and the times that this throughput

will be taking place. Size and timing of maximum throughput periods. Mixture of requests expected and how the mix varies with time. Total number of users and anticipated concurrent system usage. Assumptions regarding process performance, total workload, or

other related considerations.

Analyze

WP-048 System Sizing Requirements

Define CPU, memory, local storage and network storage requirements for each development and test environment as well as for Production and Disaster Recovery environments.

Analyze

DEL-010 Capacity Plan This plan consolidates the Capacity Plan, Technical Environments Requirements and Infrastructure Migration Plan. More specifically, the Capacity planning components of this deliverable includes the results of the process of determining the operational capacity the solution needs to achieve to satisfy the business process demands of the system as well as the number of environments required to complete development, testing, data migration and conversion activities. It should include planning through the accomplishment of the State’s long-term goal of the solution supporting all identity Management within the State, including sub recipient management, sub recipient needs, etc. This document(s) specifies by phase and system the sizing, CPU, and memory requirements.

Analyze

WP-049 Checkpoint Report – Analyze

Documents any difference in the Project scope, schedule, and/or resources at or before the end of the Analyze Phase. The focus of this deliverable will be on the scope of the solution. Also, indicates any deliverables which have not been accepted by the State per the Workplan.

Analyze

WP-050 Physical Infrastructure Architecture

This document and associated diagrams further elaborates and evolves the future state logical infrastructure architecture diagrams into the future state physical infrastructure landscape comprised of hardware, software, and infrastructure component relationships and primary end-to-end data flow between the respective components. The analysis contained in this document supports functional, data, technical and non-functional requirements as well as MDM Architectural Framework considerations.

Design

WP-051 Physical Data Architecture This document and its supporting data models and related artifacts further elaborates the logical data architecture and related models developed during the Analyze phase into the target logical and physical data architecture that enables the defined business architecture and architectural vision. Additionally, the data architecture defines:

How data entities are utilized by business functions, processes and services

How and where enterprise data entities are created, stored, transported and reported

Data transformations and complexity to support information exchange between applications

Design


Artifact, Work



Supporting data integration requirements Data definitions, models, and other related metadata

WP-052 Physical Integration Architecture

This document further elaborates the logical integration architecture into the physical integration architecture and associated artifacts which elaborates the integration approaches, methods, techniques, and communication protocols to ensure that data moves from one application to another. May also specify or design common component development, templates, and code snippets to consistently implement data integration between the Enterprise MDM data hub or supporting hub and the agency specific applications that utilize the data.

Design

WP-053 Enterprise Architecture Update physical enterprise architecture diagrams to reflect changes covered under other solution and architecture design documents that are within the scope of this RFP.

Design

WP-054 Technical Data Dictionary Captures business and technical metadata information about business data within scope of a particular data domain. This information includes standard definitions of data elements, their meanings, and allowable values. It provides more detail about each attribute within the data domain that will be used in both logical and physical data mapping, functional and technical design and during development and data conversion/migration activities.

Design

WP-055 Logical and Physical Data Models

A logical data model represents the data architecture of a specific business data domain, including relationships between data in a graphical way without regard to the physical implementation or the database management system technology involved in storing the data. A physical data model or database schema is a representation of a data design of a specific business data domain as it is intended to be implemented within the target database management system. Typically, the physical data model is derived from a logical data model, however, is may be reverse-engineered from a given database implementation.

Design

DEL-011 Updated Solution Architecture

This document incorporates updates to the Solution Architecture deliverable created during the Analyze phase to incorporate updates to the application architecture that is to be used during the project and contains the solution architecture (logical and physical components).

Design

DEL-012 Functional Design Document

Functional design of the solution. Includes the Systems Requirements Document: systems specifications and functional requirements including reliability, performance, operations, usability, maintainability and functional specifications for any interfaces to external systems.

Design

WP-056 Interface Control Document An Interface Control Document (ICD) clearly describes all possible inputs and outputs of a single system for all potential actions whether they are internal to the system or transparent to the system users. The ICD may describe the interface between two systems or the interface protocol between two physical components. The level of detail included in any ICD is dependent upon the requirements of the stakeholders to successfully deliver on project requirements. ICDs define for the development team system inputs, outputs, internal interfaces, and interfaces between other systems, subsystems and/or users. An ICD should only describe the interface itself and not any characteristics of the systems using it.

Design

DEL-013 Technical Design Document

Documents the technical specifications for the solution to include:Data definitions, identifying any new data elements and classifying new data to be added to the list of confidential and sensitive data.Unit Test scripts – including both normal and exception processingChanges to technical architectureInterfaces to external systemsAny customizations if applicable.Data Migration from external systems at deployment, if applicable.Master Data ModelMetadata Model

Design


Artifact, Work



Data Validation RulesData Control RulesETL Rules (Source, Transformation and Target)

DEL-014 Security Design Documents the details of the approach that will be followed to meet the identified security requirements of the Sate.

Design

DEL-015 Technology Environments for Development and Test

Establish the Technology Environments for Development and Testing Design

DEL-016 Data Conversion/ Migration Plan

The Data Conversion Plan (DCP) describes the strategies involved in the preparation, specifications for converting data from existing source system(s) to the target system, and related data cleansing activities that will be performed as part of the data conversion process. More specifically, the DCP includes the following:

Overall Approach and Assumptions Data Conversion Processes Inventory and cross reference of Source and Target Data

Elements, Schema, Metadata and all Self-Describing files Specific Processes for Data Extraction, Transformation and

Loading for each data source Definition of tools needed to execute the data conversion Data Cleansing processes to be performed, as required, during

Data Conversion Strategy and Processes for Data Quality Assurance and Control

Design

WP-057 Master Test Plan This document the plan, scripts (including expected results) and schedule required to execute the various tests phases, including but not limited to System Test, User Acceptance Test, and Performance Test. This deliverable also includes individual test plans for each of these test types.

Design

WP-058 Test Analysis Report Records results of the tests, presents the capabilities and deficiencies for review, and provides a means of assessing software progression to the next stage of development or testing.

Design

WP-059 QA Metrics Definition Identify and define QA Metrics that will be used during the development and testing phases of the project. These metrics will provide the project leadership team with measurements and supporting information regarding the current quality state of the project. Types of QA metrics may include:

Requirements Traceability with Test Case Coverage Test Case Execution Test Case Pass Rate Defect Metrics (Total Outstanding Defects by Severity, Days

Open, and Trend Analysis)

Design

DEL-017 Test Strategy Defines the test types and activities that will be performed during the development and testing phases of the project. It outlines the key issues and activities to be performed during the testing process and describes the testing environments and risks that are mitigated by testing. More specifically, the test strategy includes the following:

Test Rounds or Levels (e.g., Unit Testing, Integration Testing, System Testing, Performance Testing, and User Acceptance Testing)

Testing resources and their roles and responsibilities Testing Environment Requirements Testing Tools Defect Tracking Procedures Test Approach Test Environment Plan Test Schedule Test Priorities Test Status Collection and Reporting Test Record Maintenance

Design

WP-060 Stakeholder Project communications targeted towards specific stakeholder groups that will be used during design, development, testing, data conversion, and

Design


Artifact, Work



Communication Materials production deployment activities.

WP-061 Checkpoint Report – Design

Documents any difference in the Project scope, schedule, and/or resources at or before the end of the Design Phase. The focus of this deliverable will be on the scope of the solution. Also, indicates any deliverables which have not been accepted by the State per the Workplan.

Design

WP-062 Software Development Plan

The Software Development Plan (SDP) describes a developer’s plans for conducting a software development effort. The SDP describes development platform usage (e.g., Informatica Platform) and defines how monitoring will be performed during software development. It also details methods to be used and approach to be followed for each activity, organization, and resources. It should reference specific standards, methods, tools, actions, reuse strategy, and responsibility associated with the development and qualification of all requirements.

Build

WP-063 Build and Unit Test Results Provide build documentation (i.e., changes to code) as a result of unit tests conducted during the Build phase. These results also include QA metrics and trend analysis.

Build

WP-064 Component Test Results These documents are the presentation of the results from component level testing inclusive of substantiation of Contractor testing of all elements as required by the State and contained in the requirements traceability matrix.

Build

WP-065 Solution Component Code, Objects, and Configuration Technical Documentation

Technical explanation on developed source code, components, and configuration that enables application support or maintenance developers to maintain the source code. Conceptual and architectural information as well as other input is incorporated as a part of this documentation so that the developer may put the information in context. This documentation will be used during knowledge transfer activities from the development (build) team to the maintenance and operations (M&O) team.

Build

DEL-018 Solution Component Code, Objects, and Configuration

Creation of Source Code, Objects, and Informatica specific objects and configuration to implement defined functional, non-functional, and data requirements. This deliverable also includes build and unit test results, component test results and solution component code, objects, and configuration technical documentation.

Build

DEL-019 Test Scripts and Cases A test case is a set of conditions or variables under which a tester will determine whether a system or function under test satisfies requirements or works as designed (consistent with defined requirements). Similarly, a test script represents a set of instructions that will be performed on the system or function under test to verify whether the system functions are working as designed. These may be executed manually or by using an automated testing tool. Definition of these cases or scripts include user ID access restrictions, step-by-step instructions on how to execute the case or script as well as the expected results of each step.

Build

DEL-020 Operational Performance Baseline

The Operational Performance Baseline is a grouping of performance benchmarks of standardized performance measurements of overall system performance of the system under test as well as critical functional performance. These benchmarks will include performance measurements for varying volumes and concurrent user levels and will be used during performance testing activities to evaluate whether performance tests pass or fail.

Build

WP-066 Checkpoint – Test Readiness Review

Documents any difference in the Project scope, schedule, and/or resources at or before the end of the Design Phase. This checkpoint report will focus on the readiness for entering the test phase. Also, indicates any deliverables which have not been accepted by the State per the Workplan.

Build

WP-067 System Test Results These documents are the presentation of the results from a particular testing Phase inclusive of substantiation of Contractor testing of all elements as required by the State and contained in the requirements traceability matrix.

Test

WP-068 Defect List A listing of all software defects in a build of the system under test as of a point in time. The list contains the number, title, brief description of the defect, severity, priority, date identified and date resolved. A defect is a condition in a software product which does not meet a software requirement (as stated in the requirement specifications) or end-user expectations (which may not be specified but are reasonable). In other

Test


Artifact, Work



words, a defect is an error in coding or logic that causes a program to malfunction or to produce incorrect/unexpected results. The list provides a consolidated means of tracking and reporting on defects while they are being resolved.

DEL-021 System Test Results Report

A report that recaps the results of system integration testing. The test report includes the following:

Name and email address of the tester Date and time when the test was performed Scope of test, e. g. for component API testing the name and

version of the service component and the part of the API, Web Service or Batch Processing that has been tested

Test environment including operating system and type of test client, e. g. programming language and XML-RPC library used for component API testing, or Web browser used for GUI testing

Test plan, i.e. the list of test cases giving method/use case and input parameters used

Test log listing the outcome of the test case executions (manual testing or automated testing via scripts)

Summary of test results Identified defects and status of defect resolution Recommendation for action when errors had been encountered

This deliverable also includes test readiness review, system test results, and defects lists.

Test

DEL-022 Performance Test Results Report

These documents are the presentation of the results from performance testing measuring actual performance results against established performance requirement baseline for a given process or function. Performance testing results contain all performance testing inclusive of substantiation of Contractor testing of all elements as required by the State and contained in the requirements traceability matrix.

Test

WP-069 Checkpoint – Test Completion Report

This checkpoint report will focus on the readiness for exiting the test phase and entering the UAT. Also, indicates any deliverables which have not been accepted by the State per the Workplan.

Test

WP-070 System Procedures Step-by-Step instructions on how to perform a given system procedure. These procedures may be accumulated and included in an end user training guide or in system operational documentation or an operational runbook.

Test

DEL-023 System Operational Documentation

A compilation of routine procedures and operations that the system administrator or operator carries out. These procedures may be assembled in a runbook. They include procedures for every anticipated scenario, and generally use step-by-step decision trees to determine an effective response to a scenario.

Test

WP-071 User Job Aid Document A document or instruction cards, memory joggers, or wall charts, which allows an individual to quickly access the information that he or she needs to perform a task. It contains step-by-step instructions to complete the task being described.

Test

WP-072 Training Scripts Step-by-Step instructions regarding processes and procedures to be addressed as part of a training class or session to a target audience. These scripts are written specifically for the audience who will be receiving the corresponding training.

Test

WP-073 Training Guide A training guide or manual is a book or booklet of instructions, designed to educate a target audience on functionality of the system. There may be guides or manuals that are written for an IT audience versus various levels or types of business users.

Test

DEL-024 Training Materials Consolidated deliverable that consists of User Job Aid documents, training scripts and training guides used to provide business users with necessary system or other job related information as it pertains to the project.

Test

WP-074 UAT Test Plan The UAT test plan outlines the strategy that will be used to verify and ensure an application meets its business requirements. It documents entry and exit criteria for UAT, Test scenarios and test cases approach and timelines of testing. The UAT test plan is developed by business SMEs, Data Stewards, and other Data Governance representatives.

Test


Artifact, Work



WP-075 UAT Test Scripts and Cases

An UAT test case or script is a set of conditions or variables under which the Business SME, Data Steward, or other Data Governance representative will use to determine whether a system or function under test satisfies requirements or works as designed (consistent with defined requirements). Definition of these cases or scripts will be performed by the business and will include user ID access restrictions, step-by-step instructions on how to execute the case or script as well as the expected results of each step. Successful execution of these scripts and cases will serve as the foundation upon which the system is “accepted” for production deployment.

Test

WP-076 User Acceptance Test Results

These documents are the presentation of the results based on the State’s completion of acceptance testing of the Contractor developed upgrade elements. The Contractor will facilitate this deliverable and include identification, classification (i.e., Severity 1-3), and the prioritization of fixing all defects based on State UAT efforts. These results also include defect lists, prioritized defects, and defect remediation plans and level of effort estimates to resolve

Test

DEL-025 UAT Test Results Report Consolidates the UAT testing results, published defect list, prioritized defects and remediation plans for open defects at the end of the UAT test cycle.

Test

DEL-026 Data Quality Scorecard Dashboard that calculates and displays key performance indicators for the release under development. This deliverable is both the actual implementation of the score card and its results for the release under test.

Test

DEL-027 Operational Readiness Test Results

Operational acceptance testing (OAT) is used to conduct operational readiness (pre-release) of a product, service, or system as part of a quality management system. OAT is a common type of non-functional software testing, used mainly in software development and software maintenance projects. The report recaps the results of operational testing and makes a recommendation on the application’s readiness to be deployed to production.

Test

WP-077 Checkpoint – UAT Test Completion Report

This checkpoint report will focus on the readiness for exiting the UAT and entering the Deploy Phase. Also, indicates any deliverables which have not been accepted by the State per the Workplan.

Test

WP-078 Version/Release Document The Version Description Document (VDD) is the primary configuration control document used to track and control versions of software to be released to the operational environment. It is a summary of the features and contents for the software build. It identifies and describes the version of the software being delivered to the State, including all changes to the software since the last VDD was issued. Every unique release of the software (including the initial release) shall be described by a VDD.

Deploy

WP-079 Deployment Approach Detailed approach and plan for cutover activities for transitioning the in-scope processes into production. Includes:

Deployment preparation Cutover planning Stabilization planning for Post Go-Live support

Deploy

DEL-028 Deployment & Stabilization Plan

The plan will cover the timeframe before Go-Live and after Go-Live. 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. The plans will detail the following for each task:

Task name Owner Target date for completion Critical path indicator The type of tasks will include: Knowledge transfer/training tasks Operational cutover tasks (i.e., converting data, etc.) Publish revised policies and procedures Technical Architecture tasks including readiness, mock

deployments and production cutover Post Go-Live support tasks

Deploy


Artifact, Work



Approach for the project team to hand-over long term support to the run support team

DEL-029 Business Contingency/ Continuity Plan

Defines instructions and procedures that enables the State to respond to accidents, disasters, emergencies, and/or threats without any stoppage or hindrance in its operations with respect to the Enterprise MDM solution. A subset of activities within the Business Continuity Plan are actions specific for disaster recovery.

Deploy

WP-080 Job Schedule Definition A document that defines each job that needs to be run in a batch mode (or intraday processing), its parameters, other job dependencies and the general time frame that the job needs to be executed. Also, included in the definition are actions to be taken should the job not execute successfully to completion.

Deploy

WP-081 SLA Definitions and Parameters

Review Service Level Objectives (SLO) and Service Level Agreements (SLA) that pertain to maintenance and operations (M&O) as defined in Supplement 4 of this RFP. Verify calculations, parameters, and measurements for each SLO and SLA and adjust, as required, to achieve the correct measurement for production monitoring purposes.

Deploy

WP-082 Release Checklist This list contains items that need to be completed prior to the software application being released to production. The list contains the name of the individual responsible for the item, estimated time to complete and planned completion date.

Deploy

WP-083 Release Verification Checklist

The list contains items that need to be performed to verify that the release has been successfully deployed into another environment. For deployment purposes, this checklist is focused on deployment to production.

Deploy

WP-084 Audit Impact Statement Statement that summarizes that all security, privacy, and regulatory requirements have been satisfied by the project. Refer to Supplement 2 of this RFP for a discussion of these requirements and standards.

Deploy

DEL-030 Release Implementation Plan

A consolidation of the job schedule definition, SLA definitions and parameters, release checklist, release verification check list, audit impact statement, and other release implementation plan specifics that outline activities and tasks to complete deployment of the release under development into production.

Deploy

WP-085 System Deployed This is the completed production implementation of the release under development that has been reviewed and approved by the State.

Deploy

WP-086 Development Playbook A book that contains strategies for requirements, conceptual architecture alternatives, design (including design patterns), code snippets, test plans and cases to enable consistent implementation or onboarding of new agencies to the Enterprise MDM solution as well as new source and target systems. The focus of this deliverable is to make future common development efforts repeatable.

Deploy

DEL-031 System Turnover Transition solution support responsibility per the Deployment & Stabilization Plan. This includes Knowledge Transfer Activities per the Knowledge Transfer Plan. This also includes the system deployed and the development playbook.

Deploy

WP-087 Organizational Change Vision

This document defines the common vision for organization change management activities to be performed in support of the project.

Organization Change Management

WP-088 Organizational Change Sponsorship Roadmap

This document defines the organizational change sponsorship roadmap and how each stakeholder or sponsor will be engaged to support required organizational change to support long-term maintenance and operation of the data domains and agencies within the scope of the Enterprise MDM project.


DEL-032 Organization Change Strategy and Plan

This is a consolidated deliverable that contains the Organization Change Vision and Sponsorship Roadmap as well as additional information that further defines the organization change strategy and planning considerations.


WP-089 Organizational Change Analysis

This document recaps the change analysis investigation performed to support the vision and roadmap to make the actions defines within these two documents tangible in terms of specific organizational changes that will need to be made within an agency or with functions performed by workers



Artifact, Work



using a specific application system that integrates with the MDM solution. Change analysis will also include required process change for data stewards to perform their work on projects and operationally in a meaningful, effective manner.

WP-090 Organization Change Communication Plan

Defines the communication types, frequency, format, and audience for each organization change specific communication to support the defined vision and roadmap


DEL-033 Organization Change Job-Aids and Training Materials

These documents are job-aids and training materials specific to organizational and individual change required to support master data management, data governance, and data stewardship processes that are not addressed in job-aids and training materials developed for a specific project within the Enterprise MDM initiative.


A-001 Incident Report A form, or screen, containing details of Incidents involving any component of an IT Infrastructure or any aspect of the IT Service. Incident reports may come from a variety of sources and will usually result in the creation of an Incident record.

Project Incident Management

A-002 Defect Report Detail description of the identified software problem in clear, unambiguous language, along with the required steps to reproduce the error or defect. Any logs that further describe the defect are attached or included as a part of the defect report. This information allows for the developer to replicate the defect so that the code and/or configuration may be fixed and deployed to production.

Project Defect Management

6.0 State Staffing Requirements

The State will provide oversight for the Project, but the Contractor must provide overall Project management for the tasks under this Contract, including the day-to-day management of its staff. The Contractor also must assist the State with coordinating assignments for State staff, if any, involved in the Project. Additionally, the Contractor must provide all administrative support for its staff and activities. Throughout the Project effort, the Contractor must employ ongoing management techniques to ensure a comprehensive Project Plan is developed, executed, monitored, reported on, and maintained.

The Contractor must provide a Project Manager for the Work. The Contractor must employ the proposed Project Manager as a regular, fulltime employee on the Proposal submission date and throughout the term of the Contract, including all renewals. Contractor’s full-time regular employees must perform at least 30% of the effort required to complete the Project. The Contractor may use its personnel or subcontractor personnel to meet the remaining 70% of the effort.

As this project is an Enterprise offering supported by DAS/OIT and includes Agency participation in the Projects identified herein, the following table represents the State’s minimum commitments to this Project. Should, based on the experience of the Offeror additional roles be required of the State, the Offeror will identify these roles, provide rationale and include a summary description of the skills and competencies required for each position. Note that all roles (State minimum or otherwise) must be included in the Offeror’s 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 project is supported adequately.

The State will provide a dedicated State Project Lead (Project Representative) to serve as the Contractor’s day-to-day point of contact for the Project. This role will be staffed throughout the duration of the Project. The State Project Lead will facilitate process and policy decisions in support of the Project schedule. State personnel assigned to the Analyze Phase will maintain consistent involvement throughout the duration of the Project. These individuals will be accessible and available to participate as agreed upon in the approved Project Plan. Offeror


may recommend additional assistance required to successfully complete the project. This may be communicated via a RACI diagram.

Project Area

State Enterprise MDM Core

Team (DAS/OIT)

Projects

Data Management

Enterprise MDM

Solution Architecture and Current

State Assessment

Ohio Benefits Expansion

and Hardware Upgrade

Enterprise MDM

Service Integration with EDW

JFS Enterprise MDM Initiative

Medicaid Provider

ManagementOverall Project Management 1 FTE

State Standards Lead: State Policy and IT Standards

1 PTE as required

(advisory)

Security Advisor (State CISO Office)

1 FTE (design phases), part-time advisory thereafter

Privacy Advisor (State CIPO Office)


Security/Privacy SME

Up to 1 FTE as required

Business Lead


Data Analyst Lead


Data Modeler/Data Architect

-

Data Governance Lead

1 PTE As Required

Data Stewards Part Time SMEs as developed as part of Data Management Deliverables or requested by Vendor

Technical Lead -1 PTE As Required

1 PTE As Required

1 PTE As Required

1 PTE As Required

1 PTE As Required

1 PTE As Required

Integration Lead -

1 PTE As Required

1 PTE As Required

1 PTE As Required

1 PTE As Required

1 PTE As Required

1 PTE As Required

System Test Lead As required As Required As Required As Required As Required As Required As Required


Project Area

State Enterprise MDM Core

Team (DAS/OIT)

Projects

Data Management

Enterprise MDM

Solution Architecture and Current

State Assessment

Ohio Benefits Expansion

and Hardware Upgrade

Enterprise MDM

Service Integration with EDW

JFS Enterprise MDM Initiative

Medicaid Provider

ManagementSystem Test Participants As required As Required As Required As Required As Required As Required As Required

State Infrastructure Liaisons

Up to 4 PTE (Network, Server, Storage,

Directory) as required

6.1 Contract Staffing and Key ActivitiesThe Offeror is to consider the roles provided by the State as well as those proposed that are required for each Project based upon the details, the key activities, proposed time commitments required for each role, and the percent of the proposed time the role will be on the State’s premises performing work. The Offeror, as part of their response will identify all roles that are required to be performed (by phase), the work location(s) for the team and identify requirements for performing these roles off-site at an Offeror location or on State’s Premises (e.g., Project Manager, business analysis, technical lead, functional lead, etc.). Offerors are to propose a combined team organization (i.e., State and Offeror) designed to deliver the project to the State as per the requirements in this Supplement.

Offeror Team Organization, Key Personnel and Work Location(s)

Role # Offeror Role Role Activity FT/PT

On Site or Off Site

% Time On Site

Analyze Phase

[insert rows as required]

Design Phase


Build Phase


Test Phase


Deploy Phase



Role # Offeror Role Role Activity FT/PT

On Site or Off Site

% Time On Site

Post Implementation Support


6.2 Staffing Plan and Time CommitmentThe Offerors Staffing Plan and Time Commitment response must include the following information:

An organizational chart including any subcontractors and key management and administrative personnel assigned to this project

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

The number of people onsite at State location(s) at any given time to allow the State to plan for the appropriate workspace. Offeror Note: The following table is provided as an example of what the State expects the Offeror to provide in the proposal response for this requirement

Illustrative Offeror Staffing Plan

Project Month 1 2 3 4 5 6 7 8 9 10 11Phase Startup /

Analyze Design Phase Build Phase Test Phase Deployment Operate

Project ManagementState 3 3 3 3 3 3 3 3 3 3 3

Offeror 2 2 2 2 2 2 2 2 2 2 2Functional FTEs

State 4 4 4 4 4 4 4 4 4 4 4Offeror 8 8 8 8 8 8 8 8 8 8 8

Technical FTEsState Infrastructure 2 2 2 2 2 2 2 2 2 2 2

State Security 1 1 1 1 1 1 1 1 1 1 1Offeror 6 6 6 6 6 6 6 6 6 6 6

Business / Agency FTEsState 4 4 4 4 4 4 4 4 4 4 4

Offeror 2 2 2 2 2 2 2 2 2 2 2Summary Total

State 14 14 14 14 14 14 14 14 14 14 14Offeror 18 18 18 18 18 18 18 18 18 18 18

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 Offeror 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 OAKS enterprise Service.


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

In addition, the Offeror’s proposal must identify all Key Project Personnel who will provide services as part of the resulting Contract. The Key Project Personnel are identified in each applicable Supplement. The State expects that the proposed named Key Project Personnel will 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

Proposed role on this Project

Listings of completed 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

6.3 Background ChecksAll Contractor and subcontractor personnel assigned to the Enterprise MDM Project who have access to sensitive or confidential information or to sensitive State systems must have a current fingerprint search and background check performed by the Federal Bureau of Investigation or other Federal investigative authority. The fingerprint search and background checks must be completed before any such Contractor or subcontractor personnel gain access to State facilities, sensitive and/or confidential information or systems. All costs associated with this requirement will be at the Contractor’s own expense. At its discretion, the State may reject any Contractor or subcontractor personnel based on the information provided in the completed background check.

The Offeror must confirm in their Proposal that all Offeror and subcontractor personnel assigned to the Project will have Background Checks completed before Project Start or before reporting to State designated Project facilities.

7.0 Assumptions

The Offeror must list all the assumptions made in preparing the Proposal in the “Template P General Assumptions” document. 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.

7.1 Support RequirementsThe Offeror must describe the support it wants from the State other than what the State has offered in this RFP. Specifically, the Offeror must address the following:

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

Assistance from State staff and the experience and qualification levels required

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.

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

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

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 4 may result in a rejection of the Offeror’s Proposal.

8.0 Informatica Platform Environments

This section defines the Informatica development and testing related environments that need to be implemented as part of the scope of this RFP. Additionally, the Contractor will need to provide technical support for these environments throughout the system development lifecycle for all releases that are within the scope of this RFP.

8.1 Informatica Platform Environment Implementation and Support During Development

The following environments need to be procured and implemented as part of the scope of this RFP. Please note that the State has already acquired an enterprise license for all Informatica products to be used in these environments.

Environment Usage Quantity

Development To perform application development for releases included in the scope of this RFP

2

System Testing To perform system integration testing and UAT defect correction validation testing prior to deploying the change in UAT

2

UAT To perform user acceptance testing 2

Prod Replica Restricted environment that contains a replica of production data. This environment is used to test external web services, such as the Federal Data Hub, where production data is needed to successfully complete this testing. This environment may also be used for performance testing.

1

Prod Production environment where the releases will be used by the business users working for agencies within the scope of this RFP

1

Disaster Recovery Disaster recovery environment to fail over onto in the event of a production system outage due to a natural disaster or other unforseen event

1

9.0 Appendix A: Project Development Methodology Deliverables by Release

Below is a matrix of required deliverables and key work products by project as outlined in Section 2 of this Supplement.

