ohio workforce system transformation project system ... · web viewthe requirements for the ohio...

Supplement 1:Ohio Workforce System Transformation (OWST)Scope of Work

OWST Project RFP State of Ohio p 1

Table of Contents1. OHIO WORKFORCE SYSTEM TRANSFORMATION PROJECT SYSTEM REQUIREMENTS 5

System Project Management Requirements (Table A).................................................5Ohio Workforce System Transformation Business Requirements (Table B)...............5Ohio Workforce System Interface Requirements (Table C).........................................5Common Functional Requirements (Table D)..............................................................5Program Services Requirements (Table E)....................................................................5

2. ODJFS PROJECT OPERATIONAL AND ADMINISTRATION SUPPORT................................5

3. SITE TRANSITION..............................................................................................................................6

3.1 State-owned Data.....................................................................................................63.2 State Owned Capabilities.........................................................................................63.3 Site Conversion........................................................................................................73.4 Constraints...............................................................................................................73.5 Automated Conversion Methods:............................................................................73.6 Manual Conversion Methods:..................................................................................83.7 Conversion Prerequisites:........................................................................................83.8 Conversion Procedures:...........................................................................................83.9 Resource Requirements:..........................................................................................83.9.1 Conversion Responsibilities:..............................................................................83.9.2 State Conversion Responsibilities:....................................................................9

4. EXIT STRATEGY.................................................................................................................................9

5. PROPOSED PLATFORM FUTURE ENHANCEMENTS.............................................................10

5 TABLE A: SYSTEM PROJECT MANAGEMENT REQUIREMENTS.......................................11

6 TABLE B: BUSINESS REQUIREMENTS.......................................................................................23

B.1 General System Capabilities.................................................................................23B.2 Technology Driven Capabilities...........................................................................27B.3 Flexibility & Automation Capabilities..................................................................27B.4 Program Management Capabilities.......................................................................28B.5 OhioMeansJobs.com (OMJ) Integration..............................................................31B.6 Comprehensive Assessment and Services............................................................32B.7 Case Intake and Eligibility...................................................................................34B.8 Training Providers.................................................................................................35B.9 Employer Services................................................................................................36B.10 Fiscal Management.............................................................................................37B.11 Communication, Forms and Notices...................................................................38B.12 Reporting.............................................................................................................39B.13 Usability..............................................................................................................42B.14 System Administration........................................................................................43B.15 County Data Integration......................................................................................44

7 TABLE C: INTERFACES..................................................................................................................44

C.1 Interfaces...............................................................................................................44C.2 Interface Interoperability.......................................................................................47

9 TABLE D: COMMON REQUIREMENTS.....................................................................................49

D.1 Security and Recovery......................................................................................49OWST Project RFP State of Ohio p 2

D.2 Identity Management........................................................................................50D.3 System Performance and Capacity...................................................................50D.4 Hosting...............................................................................................................51D.5 Single Sign-on...................................................................................................52D.6 Work Flow.........................................................................................................52D.7 Help Search........................................................................................................53D.8 Security User Interface......................................................................................54D.9 General...............................................................................................................55

10 TABLE E: PROGRAM SPECIFIC REQUIREMENTS................................................................56

E.1 WIOA Adult and Dislocated Workers..................................................................56E.2 WIOA Youth Program (CCMEP).........................................................................58E.3 Rapid Response and Layoff Aversion..............................................................60E.4 Veterans............................................................................................................62E.5 RESEA and UCRS...........................................................................................64E.6 Wagner Peyser (Labor Exchange).........................................................................66E.7 Re-Entry (REO).................................................................................................66E.8 Migrant Seasonal Farm Workers.......................................................................67E.9 Foreign Labor Certification FLC..........................................................................68E.10 Apprenticeship....................................................................................................70

11 TABLE F: TRADE PROGRAM SPECIFIC REQUIREMENTS - OPTIONAL.........................71

F.1 Trade - Optional....................................................................................................7112 TABLE G: WOTC PROGRAM SPECIFIC REQUIREMENTS - OPTIONAL..........................75

G.1 WOTC - Optional.................................................................................................7613 TABLE H: CFIS PROGRAM SPECIFIC REQUIREMENTS - OPTIONAL.............................78

H County Finance Information System – Optional.....................................................7814 TABLE I: LABOR MANAGEMENT INFORMATION PROGRAM SPECIFIC REQUIREMENTS - OPTIONAL86

I Labor Market Information - Optional.....................................................................8715 TABLE J: DOCUMENT IMAGING SPECIFIC REQUIREMENTS - OPTIONAL..................87

J Document Imaging Features - Optional...................................................................8816 TABLE K: JOB SEEKER INTERFACE SPECIFIC REQUIREMENTS - OPTIONAL...........89

K Job Seeker Interface Features - Optional................................................................90K.1 WIOA Tablet Interface.........................................................................................90K.2 Trade Tablet Interface...........................................................................................91

17 SERVICE LEVEL AGREEMENTS - OPERATIONS....................................................................93

17.1 Parties and Timeline......................................................................................9317.2 Service Catalogue.........................................................................................9317.3 Deductions.....................................................................................................9317.4 Reporting.......................................................................................................9317.4.1 Weekly Status Report....................................................................................9317.4.2 Monthly Review Meeting..............................................................................9417.4.3 Quarterly Review Meeting............................................................................9417.4.4 Reporting Service Levels...............................................................................9417.5 User Support and Problem Correction...........................................................9417.5.1 Prioritization Approach.................................................................................95


17.5.2 Application Function Type............................................................................9517.5.3 Response and Resolution Times....................................................................9617.5.4 Response and Resolution Service Levels......................................................9717.5.5 Application Availability................................................................................971575.6 Application Availability Service Levels.......................................................9817.5.7 Application Responsiveness Service Levels.................................................98


Supplement OneOhio Workforce System Transformation - OWST Requirements

The Contractor must implement the System with all required interfaces and all data conversions within twenty-four (24) months from the date of the executed contract. Any required schedule will become part of the contract.

1. Ohio Workforce System Transformation PROJECT SYSTEM REQUIREMENTSThe requirements for the Ohio Workforce System Transformation project are found in the attached tables. The State has worked to keep the requirements at as high a level as possible to take full advantage of an existing operational core system. Each requirements table has sections that consist of critical and desirable requirements. All requirements will be evaluated and rolled up into the score given for the particular section of the requirements table. Tables F, G, H, I, J and K contain requirements for optional modules. ODJFS has provided entries on the cost proposal form for separate cost quotes for these modules.

System Project Management Requirements (Table A)

Offerors must describe how they will implement an OWST Project solution in response to the Implementation Requirements. These requirements are found in Table A: System Project Management Requirements to this RFP. Offerors must respond to all requirements.

Ohio Workforce System Transformation Business Requirements (Table B)

The Business Requirements describe the desired high-level features of the Ohio Workforce System Transformation Project from a business perspective. These requirements are found in Table B: Ohio Workforce System Transformation Business Requirements, to this RFP. Offerors must respond to all requirements.

Ohio Workforce System Interface Requirements (Table C)

The Business Requirements describe the Ohio Workforce System Interface high-level details. These requirements are found in Table C: Ohio Workforce System Interface Requirements, to this RFP. Offerors must respond to all requirements.

Common Functional Requirements (Table D)

The Common Requirements describe the capacity, performance, security, and processes of the OWST Project. These requirements are found in Table D: Common Functional Requirements to this RFP. Offerors must respond to all requirements.

Program Services Requirements (Table E)

The Program Services Requirements describe program specific Ohio customization requirements, delineated by a leading OH, and provides program specific capabilities which is in addition to the above Table B: OWST Business Requirements. These requirements are found in Table E: Program Services Requirements to this RFP. Offerors must respond to all requirements.

2. ODJFS Project Operational and Administration Support

Provide your estimate of the number of ODJFS staff hours by category (e.g., subject matter experts, test, technical support, project management), that contribute to the deliverables (ODJFS Hours). Offeror is not expected to provide dollar cost estimates for ODJFS staff hours.


3. Site Transition

As the new system promotes online, we will need data and capability conversion support in transitioning the existing Ohio data and capabilities to the new solution provider. At the start of the Contract, the Contractor agrees to:

3.1 State-owned Data

The Contractor must identify and document to the State all State-owned data in the system inclusive of volumes, record layouts, database objects and historical record counts. The Contractor must work with the State, and the State-owned data, to establish a periodic data handoff procedure inclusive of all State identified data. Along with periodic handoff. the State requires a complete dump of all data prior to the conclusion of the Contract. As part of this handoff procedure, the Contractor must work with the State to establish data conversion and formatting standards (e.g., file formats, record layouts or XML based structured files) as well as data extraction/conversion control reporting to ensure that all State data is extracted and provided as per the State’s requirements. The Contractor must execute required data conversions or extractions including, but not limited to all State data and ancillary supporting data as required by the system to be readable by the State and serve as the basis for State onward use of the data. This will be executed once with a subset of the data to test and confirm the process and then again quarterly to get latest data delivered to support the transition.

The State of Ohio data must be removed from all Contractor systems (and their subcontracted systems) and repositories once the site transition has been successful, unless the State of Ohio has granted explicit permission for the Contractor to retain specific data.

The Contractor must: Convert electronic data into a format, approved by the State, to be used by the State using a data

conversion program; Perform required data matching activities and error reporting; Document data issues and provide to the State for resolution; and Coordinate and confirm the State approval of data conversion results.

The Contractor must transfer all State-owned data to the State on a quarterly interval until the site transition is complete.

3.2 State Owned Capabilities

The Contractor must identify and document to the State all State-owned capabilities in the proposed system; this includes work done by the Contractor as well as their subcontractors in support of the State of Ohio. The Contractor working with the State, and the State-owned capabilities, will establish a handoff procedure approved by the State. As part of this handoff procedure, the Contractor will work with the State to establish the transfer of the intellectual property (IP) with all that is necessary to have it fully functional in the State’s environment. This handoff will include all environmental information and any proprietary tools needed to allow the State to be able to get the capabilities transferred and fully functional.

The Contractor agrees to execute required IP handoff once at a mutually agreed upon point and then again after any final updates are made before the start of the transition; and support the State in getting the transferred functionality up and operational on State facilities.

The Contractor must coordinate and confirm the State approval of handoff results.


3.3 Site Conversion

The Contractor must provide a complete site conversion plan within 3 months of award of the Contract. The plan needs to address:

The mapping of data from the existing system to the new solution; Definition of any new defaults for required data in the new system; The strategy for converting the system – both data and software tools and capabilities; Assessment of the need for any manual conversion and plan; Backup and rollback strategy due to failed attempt; Any outage time for the site while the conversion is in flight; Contractor assumptions about JFS resources requirements; Contractor and State roles and responsibilities; Assumptions and constraints; and Capture any additional data required for the initial operation of the new OWST solution.

3.4 Constraints

All logins will need to be re-established on the new solution with the existing login and password;

All logins will be driven to a password reset on first login to the new solution; The State of Ohio will identify a set of pilot users to support a “pilot” on the new system; and All of the current accounts need to be moved in one block before the new site can go into

service.

3.5 Automated Conversion Methods:

Whenever possible, the Contractor must use automated methods to consolidate, validate, and transfer in the approach to converting data including, but not limited to the options as outlined below:

Conversion of External System data; Automated Client Data Consolidation Methods; Automated Data Validation and Editing Methods; Data that contains missing files; Data that contains missing field values; Data that did not pass automated editing routines; Data which requires some manual validation of the values assigned to certain fields; Conversion Clean-up documents will be generated by the system and will be distinguished

from exception reports in that the documents themselves will be used to record new or missing data;

Automated processes will screen for duplicate clients and cases during building of the Conversion Shadow Databases and the statewide new OWST databases. Exceptions will be noted and reported for resolution;

Other batch programs will be designed to modify data elements by defaults or calculations to assure that values stored in new OWST databases are accurate; and

Special on-line and utility programs will provide for the entry of data corrections into the Conversion Databases during the data validation process.


3.6 Manual Conversion Methods:

One of the primary objectives of this conversion will be to minimize and possibly eliminate the need for any manual data entry or data clean-up whenever it is determined feasible. However, automated conversion methods must be augmented by a series of manual conversion methods to ensure that the data consolidation, validation, and transfer are both comprehensive and valid and are completed in a controlled and organized manner.

3.7 Conversion Prerequisites:

There are a number of prerequisite conditions which must be met before the entire conversion effort can begin. These are referred to as "conversion prerequisites" as they represent critical dependencies for the start-up of the conversion. A delay or failure to deliver any of these essential elements which follow would require a change in the conversion strategy and schedule. The following conditions must exist before the statewide conversion can begin: The conversion programs must be completed, fully tested, and accepted by the State of Ohio so

that conversion activities can lead directly into full production operation using the comprehensive system;

As soon as the transferred software is fully functional, the State staff will have access to an acceptance test area to confirm that it continues to meet the existing requirements. This will happen no later than 3 months before go-live. The transferred software is expected to be production ready at this point;

The State staff will be trained in the process for input of that data which is critical to the new operation in order for the full scope of the conversion approach outlined in this plan to proceed as planned;

The complete training environment required to support the new installation must be in place, including approved new training guides and materials, a fully equipped and linked central training facility, a group of qualified trainers, and the full commitment of State staff's time to the conversion;

A complete system support network must be in place and operational prior to the start of conversion activities, including HELP Desk staff knowledgeable in how to resolve problems arising during conversion and on-going operation of the new solution, qualified operations staff who operate the system during implementation, and a stable processing and communications environment; and

The State will establish and staff a parallel OWST Help Desk in time for that staff to be trained and available to support the conversion activities.

3.8 Conversion Procedures:

Data validation must be performed, by the Contractor, locally and corrections must be made to the Conversion Shadow Databases through data entry. The contents of the Conversion Shadow Databases will not be migrated to the new OWST statewide databases until it is confirmed that:

All potential duplicates have been eliminated; All outstanding data edits have been researched and resolved; and All outstanding data validation reports have been handled according to the State-approved

conversion approach.

3.9 Resource Requirements:

3.9.1 Conversion Responsibilities: The Contractor must be responsible for:


The receiving and intake of the existing transferring software and support files to become a part of the supported base of the new site;

The development and documentation of an approach to converting data from External System and Current System;

The delivery of a detailed Work Plan that will cover the activities and deliverables. Also, it will include effort hours by staff for each activity;

The preparation and delivery of Data Mapping documents which display the mapping of data in the old system to the New System;

The delivery of conversion specifications for each program needed for conversion or data clean-up;

The development (coding and unit testing) of the conversion programs; The function/system testing and delivery of the conversion software for New System; The executing of conversion programs at the proper time, and for cooperating with the State to

ensure a smooth transition from Current System to New System statewide; and Playing a supportive role throughout the conversion and statewide implementation period by

jointly monitoring progress, anticipating problems, correcting faults, and facilitating resolutions along with State and the Contractor’s Quality Assurance Team.

3.9.2 State Conversion Responsibilities: The State staff will be responsible for:

Providing database layouts for the Current System databases and file layouts for both Current System files and External System Client File;

Reviewing all delivered documentation from the awarded Contractor conversion team; Creation of any forms and the procedures required for the manual gathering of missing

required data; Determining the defaults, the default calculations and algorithms to be used to populate New

System required data that is not available in Current System; User Acceptance Testing (UAT) of the conversion migration and clean-up programs; Monitoring the Pilot test for any changes to previously defined procedures prior to statewide

conversion activities; Determining the conversion schedule for the Customer local office after the completion of the

Pilot phase; and Playing a primary role throughout the conversion and statewide implementation period by

monitoring progress, anticipating problems, correcting faults, and facilitating resolutions along with the support of Contractor Conversion.

4. Exit Strategy

Within 6 months of the award of the Contract, the Contractor and ODJFS will document the exit strategy for a time when the system no longer is the correct solution for the State of Ohio. This exit strategy will outline the process, timeline intervals, and ongoing commitments for each side for agreements on termination.

The Contractor must provide transition assistance services to the State, or at the State’s request to the State’s designee to allow contracted services to continue without interruption or adverse effect and to facilitate the orderly transition to a new service provider.

Transition Assistance Services must commence as follows:


No less than six (6) months prior to expiration of this Contract or on such earlier date as the State may request; or

Upon notice of termination/partial termination; or Upon notice of non-renewal of this Contract.

For a period of up to three (3) months following the effective date of expiration, termination or non-renewal, at the State’s request, the Contractor will continue to provide Transition Assistance Services.

Upon State request, the Contractor must provide Transition Assistance Services that include, at a minimum:

Provide assistance, cooperation and information as is reasonably necessary to help enable a smooth transition of the applicable Services to the State or its designated service provider;

Provide information as the State may reasonably request relating to the number and function of each of the Contractor personnel performing the Services;

Transfer State-owned data, information, deliverables, work products, documentation, etc. a minimum of 4 times;

Identify any dependencies on the new service provider necessary for the Contractor to perform the Transition Assistance Services;

Assist the State in the identification of significant potential risk factors relating to the transition; Assist the State in designing plans and contingencies to help mitigate identified risks; Submit a Transition Plan, for approval by the State, which includes a timeline for successfully

completing the Transition Assistance Services; and A schedule and plan for Contractor’s return to the State of (i) the State service locations then

occupied by Contractor (if any), and (ii) the State Confidential Information, the State Data, documents, records, files, tapes and disks in Contractor’s possession.

The Contractor must provide a single point of contact who will be responsible for Contractor’s overall performance of the Transition Assistance Services.

5. Proposed Platform Future Enhancements

The offeror must describe the planned future capabilities of the proposed solution. Future enhancements plans will not be scored, however, will be reviewed by the evaluation team during offeror demonstrations. ODJFS is looking for a solution that is flexible and is able to meet future business needs.


5 Table A: System Project Management RequirementsRequirement Type definitions: C is a critical component of the System. D is a desirable component of the System.

System and Project Management RequirementsRequirement Type Offeror Response

A.1 The Contractor must manage the relationship among its staff and its subcontractors.

C

A.2 The offeror must describe their approach to working with ODJFS through each phase of the project, describing how they would collaborate with ODJFS on specific project-related functions, including requirements gathering, configuration, testing, and training. The Contractor must pay all expenses for travel to and from ODJFS sites.

C

A.3 The Contractor must verify that all Contractor and subcontractor staff have signed ODJFS non-disclosure agreements prior to commencing work on the project. Depending on the role of the individual, there may be several forms to be signed to ensure data is held safe.

C

A.4 The Contractor must use an industry standard Project Management methodology to provide the services as described by the Deliverables and System requirements. ODJFS is interested in an approach (e.g. Agile) that will deliver customer-facing value early in the project and in frequent increments throughout the project. The offeror must describe prior projects where the methodology was able to deliver value in such a manner.

C

A.5 The Contractor must jointly manage the System with the ODJFS Project Management Team including a lead from both the Office of Information Services (OIS) and Office of Workforce Development (OWD).

C

A.6 The Contractor must provide, as part of the Contract resulting from this RFP, the following Deliverables:

Project Plan:

C



o A Project Management Plan including milestones, schedule, communication plan and resources.

Detailed Design Document: Data Conversion; System Installation and Configuration; Training and Knowledge Transfer; System Documentation; e.g. requirements,

architecture, class/state/sequence diagrams, business flows, validation/verification and testing, help guide;

Project Change Control Process; Final System Acceptance; Escalation plan; Executive Steering Committee – roles and

responsibility; and Organizational Change Management Plan.

A.7 The offeror must outline the tools to be used for management of the Software Delivery Lifecycle during Project implementation and maintenance period in the following areas:

Project Planning; Project scheduling; Word processing and spreadsheets [for all

document-based deliverables]; Document repository; Management of the software customization and

configuration process [including issues, System deficiencies, and testing documentation];

Requirements and development tracing; and Test planning and tracking.

C

A.8 The proposed Project Plan must include tasks, a schedule and resources from System project initiation to System

C


System and Project Management RequirementsRequirement Type Offeror Responseproject implementation in sufficient detail to allow project monitoring.

A.9 The proposed Project Plan must be updated and kept current, at least at two-week intervals, throughout System customization, configuration and implementation.

C

A.10 Offeror must conduct a Kick Off Meeting. The Contractor, in conjunction with State staff, must plan and conduct a Project kickoff meeting.

The Contractor in collaboration with the State will initiate the project with a mobilization effort for the first 15 days of the project, followed by the project kick-off event. This effort will focus on planning, processes, and project methodology. The goal will be to discuss and evaluate the Contractor’s proposed practices, methodologies and recommendations and ensure Contractor’s understanding of their commitment to deliver the proposed solution for the project. The Contractor must also work with the State on establishing acceptance criteria prior to submitting a deliverable.

The Contractor in conjunction with the State must develop and deliver a presentation to the sponsors, key stakeholders and core project team after the mobilization effort. At a minimum, the presentation must include a high-level overview of the following:

Project scope and schedule; Goals of the Project; Methodology, approach, and tools to achieve the

goals; Roles, responsibilities, and team expectations; Tasks, Deliverables, Milestones and significant

C



work products; and Contract content review.

A.11 Offeror must conduct Project Review Check Points.

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); and

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

C


System and Project Management RequirementsRequirement Type Offeror ResponseProject, within one week of the meeting, which may include the following:

Continue the Project; Terminate the Contract; or Suspend the Contract. Please 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.

A.12 Offeror must describe approach to requirements gathering, along with a description of prior projects where the approach was used to collaborate with customers to develop rapid requirements and deliver customer-facing value early in the project.

C

A.13 The Contractor must provide as part of the Contract resulting from this RFP a Test Plan for the System, including the following:

How it will conduct Data Conversion, Integration, System, Functional, Performance, Security, and User Acceptance Testing;

How it will conduct Mobile Device and Application Testing;

How it will conduct Regression Testing; How it will test documentation to ensure that it

accurately describes the System functionality; How it will provide certification (including

documentation) of completion of Data Conversion, Integration, and System Testing prior to handing the System to ODJFS for User Acceptance Testing;

How it will involve ODJFS staff in Integration

C



and System Testing; and How it will assist ODJFS staff in User

Acceptance Testing.

Must describe how the Contractor or Subcontractor has successfully tested its solution on prior similar projects.

A.14 The Contractor must be responsible for conducting, documenting, and communicating Unit, Data Conversion, Functional, Integration, Security and System Testing.

C

A.15 The proposed solution must be useable by a wide variety of end users. Must describe offeror’s approach to usability and describe usability testing that offeror has conducted with its proposed solution. ODJFS reserves the right to conduct usability testing at its own expense in the State’s usability lab prior to implementation.

C

A.16 The Contractor must assist ODJFS in the design of the User Acceptance Test(s).

The Contractor must assist ODJFS in conducting the User Acceptance Test(s) and providing suitable environments for conducting such tests.

C

A.17 The Contractor must document testing activity including scripts, modules tested, deficiencies detected, and remedies implemented for System and for System Interfaces.

C

A.18 The Contractor must support testing with appropriate data and system configuration changes to support testing of all daily and periodic activities.

C

A.19 The Contractor must conduct knowledge transfer to ODJFS’s technology staff including, but not limited to:

Content Management; System design and schema;

C



System usage; System testing techniques (manual and

automated); System procedures; Application and tools development; Report generation; Data and Database Administration; Utilities; Application Diagnostic Tools; and System administration and maintenance.

A.20 The Contractor must update the System documentation, including, but not limited to:

Reference manuals; Data Conversion process and results

documentation; Data Architecture; Dependency documentation; Requirements specifications; Design documentation; Functional specification; User Interface documentation; Technical Interface documentation; Quality Management activities; Test Plans; User Manual; Online Help; System Manual; System Administration Manual; Help Desk Manual; Documentation (i.e., changes to requirements,

use cases, business rules); Training Manuals and Materials; and Data Maps for Extracts.

C

A.21 The Contractor must make System documentation C


System and Project Management RequirementsRequirement Type Offeror Responseavailable in written manuals in electronic form, and accessible online as part of a help facility for the System.

A.22 The Contractor must have an internal quality management function that will use:

Internal Quality Assurance (QA) checklists and Quality Audits; and

Internal Quality Control (QC) checklists and inspection.

Regular QA reports must be provided to ODJFS using the metrics from the above processes.

Offeror must provide a description of approach to Quality Management and how offeror or sub-contractor managed quality on prior projects.

C

A.23 Contractor must provide a Risk Management Plan as part of the contract resulting from this RFP for System including:

Methodology (approaches, tools, frequency of reviews);

How risk documentation will be utilized and populated;

How risks will be monitored and controlled; and How Risk Mitigation and Contingency Plans will

be developed and implemented.

C

A.24 Offeror must describe its approach to implementation including, but not limited to:

Proposed Schedule; Communications; Acceptance and exit criteria; How it will manage multi-staged

implementation; and

C



How it will manage implementation with no disruption to the business or Systems in use by ODJFS.

A.25 Contractor must be responsible for a training plan and knowledge transfer to users on the functionality of the System. Classroom training is preferable.

C

A.26 The website design rendering must be browser neutral. The website must be thoroughly tested for compatibility with major browsers (Windows: IE, Chrome, Firefox, Opera, Netscape; Mac: Safari) and two versions backward compatibility with screen resolution neutrality.

C

A.27 Compatible browsers information must display on each page of the site including “white-labeled” or third-party tools.

C

A.28 Must ensure system is continually tested for current browsers for updated and/or new content. Must have the site compatible within 6 months of a new browser release date and remain backward compatibility for two versions back.

C

A.29 ODJFS seeks a system which delivers a good experience on multiple devices, including PC's, tablets, and a variety of smartphones. Offeror must describe their strategy and approach to meeting this requirement, including whether the offeror utilizes a responsive web design approach or dedicated mobile apps.

C

A.30 Provide a logical network diagram that describes how the infrastructure components will meet the functional requirements.

C

A.31 Provide conceptual and logical data-flow diagrams. CA.32 Provide a high-level architecture diagram, including

logical and physical components. C

A.33 System documentation must describe error logging and how to access the error logs.

C



A.34 System documentation must describe any batch processing requirements for the application.

C

A.35 A detailed network/server diagram must be provided illustrating the relative architecture of the proposed system. It must include:

Network security zones and firewalls; Server types and network components (e.g.,

switches); Ports and protocols used to cross security zones; How users will access the system; and Clustering of servers.

C

A.36 System documentation must clearly describe all versions of the package that are deployed for different scaling situations.

C

A.37 System documentation must clearly describe all activities that affect optimum performance such as service recycling, rebooting, or batch jobs and their frequency.

C

A.38 Provide conceptual and logical application data-flow models.

C

A.39 Conversion: Must describe their strategy and approach for data conversion, including descriptions of prior similar projects.

C

A.40 Must provide conversion of data from the current workforce case management system into the proposed system which is sufficient to provide a historical record of participant records and employer services based on federal requirements.

C

A.41 Must describe how the system security supports role- based security and protects access to sensitive data.

C

A.42 Must provide a recovery plan for restoring services in the event of a disaster including system and data restoration.

C

A.43 Offeror must describe the encryption used to protect COWST Project RFP State of Ohio p 20

System and Project Management RequirementsRequirement Type Offeror Responsesensitive data, both in transit between users and the provider, and while data is stored at rest.

A.44 Offeror must agree that all ODJFS data that it hosts will be hosted only in data centers located inside the United States.

C

A.45 Offeror must agree that all data stored in the application is the property of the State of Ohio. Offeror must also agree to periodically provide copies of the state data to ODJFS and when the contract expires or is terminated. Offeror must certify the destruction of any remaining copies in its systems.

C

A.46 Offeror must agree to notify ODJFS in the event of compromise or other unauthorized access to ODJFS data. Must describe policies in the event of a privacy breach.

C

A.47 Offeror must certify that it will either use discrete data storage for the Service provided to ODJFS or if it collocates ODJFS data with data of other customers, have a documented set of controls that it uses to ensure the separation of data and security information between customer applications.

C

A.48 The proposed solution must have a completed Project Security Plan and Assessment before Go Live.

C

A.49 The proposed solution must have built-in security controls and meet or exceed current State security requirements as described in Supplement 2.

C

A.50 The proposed solution must complete implementation and provide a production system within 24 months of contract award.

C


6 Table B: Business RequirementsIn addition to the general requirements outlined in Table D: Common System Requirements, a technology solution must provide the capabilities identified in the following business requirements. Please describe the capabilities and functionality that would be provided which will meet these requirements.

In the “Offeror Response” Section, offerors must check the applicable box to indicate whether the requested functionality is a core System capability, a configurable option, or requires custom development by offerors.

In the “Narrative” box, the offeror must provide a response describing how the System performs the functions described in each section or subsection.

Requirement Type definitions: C is a critical component of the System. D is a desirable component of the System.

OWST Business RequirementsType Offeror Response

Check Applicable Box NarrativeCore

CapabilityConfiguration

OptionRequires

Development

B.1 General System CapabilitiesB.1.1 The System must provide Veterans Priority of Service for all

programs administered through the system.C

B.1.2 The System must provide access to the tables that will allow ODJFS to make system changes when necessary.

C

B.1.3 The System must have the ability to easily transfer cases from one staff to another staff (all programs).

C

B.1.4 The System must have spell check for notes/comment section (system wide for all programs).

C

B.1.5 The System must have the ability to expand the case notes/comment area under Participant and Non-Participant Services for viewing ease (system wide for all programs -sortable by date or program.

C

B.1.6 The System must have the ability to run reports on every field in the system with the ability to pull it by state, local area, county, case, and individual.

C

B.1.7 The System must have functionality for electronic signature and the ability to print for all program assessments.

C

Ohio OWST Project RFP State of Ohio p 22




OptionRequires

DevelopmentB.1.8 The System must provide the ability to view program

progress in the form of a dashboard-visual representation by county of program results.

C

B.1.9 The System must provide the ability to upload data to the case management system from Ohio's various 88 counties unique system.

C

B.1.10 The System must have the ability to accept basic intake and basic demographic data via internal and/or external data sharing uploads.

C

B.1.11 The System must have roles supporting an organizational Hierarchy.

C

B.1.12 The System must restrict access to special grant programs to only those users granted the correct user role.

C

B.1.13 The System must provide functionality for Case Management with Individual Plan and tracking of services.

C

B.1.14 The System must have the ability to identify and report potential issues, negative outcomes, which may be the basis for disqualification from UI benefits. Often referred to as ‘negative reporting’. These situations include, but are not limited to, failure to apply for job referrals, failure to accept work offered and failure to report to job interviews and other reemployment activities.

C

B.1.15 The System must support collection and retention of Employer Services data. This data will come from OMJ or local screen input and be kept in the Employer database; utilized by every program for job placements and providing services to employers.

C

B.1.16 The System must archive data for retention, then purge data after 7 years.

C

B.1.17 The System must have a Centralized database/Repository for easy reporting.

C

B.1.18 The System must have data export capabilities to Excel for case load and performance reporting.

C





OptionRequires

DevelopmentB.1.19 The System must support program integration and service

delivery must be in alignment with Title I and Title 3 programs.

C

B.1.20 The System must have the ability to dual enroll customers in multiple programs with the ability to view all programs.

C

B.1.21 The System must have the ability to upload certified worker data in multiple formats (.xls, .csv, etc.) into the case management system (system of record).

C

B.1.22 The System must have the ability to add individual worker data to the case management system.

C

B.1.23 The System must have the ability to export data/reports to Excel and in PDF format for analysis and distribution.

C

B.1.24 The System must have separate work queues for the petitions, service delivery, and contract staff.

C

B.1.25 The System must have a determination and appeal structure for training contracts, job search allowances, relocation allowances, and other TAA benefits.

C

B.1.26 The System must have the functionality for Case Managers with Individual Opportunity Plan and tracking of services.

C

B.1.27 The System must serve as the single repository/source for program reporting purposes.

C

B.1.28 The System must provide a feed to the State of Ohio print shop to generate and mail correspondence to individuals and/or training providers/employers.

C

B.1.29 The System must have the ability to identify customers with multiple (back to back) petitions.

C

B.1.30 The System must provide internal referrals/alerts from program to program.

C

B.1.31 The System must have an intuitive calendar for scheduling appointments.

C

B.1.32 The System must be intuitive so that it can provide step by step screens for every program to assist in reducing errors and inconsistencies.

C





OptionRequires

DevelopmentB.1.33 The System must have the ability to send automated emails. CB.1.34 The System must have the ability to generate mass

emails/texts to individuals seamlessly.C

B.1.35 The System must have the ability to use Surface Pros in the Resource Room to capture participant activities (i.e. check in customers and track progress).

C

B.1.36 The System must have the ability to link the customers information/events with Outlook.

C

B.1.37 The System must have the ability to capture and offer eligibility, dual enrollment, track and monitor services, job placements and follow up across various programs to ensure coordination of services.

C

B.1.38 The System must have robust general capabilities, including but not limited to, person and business searches (including phonetic and wild card), general notes and individual user productivity tools (e.g. calendar, messages, spell check, etc.).

C

B.1.39 The System must have comprehensive processing capabilities/controls to ensure transactional and data integrity is maintained. This includes, but is not limited to on-line transaction edits, capture of user/date/time information for all transactions and maintaining a history file of transactions, events and activities.

C

B.1.40 The System must track the before/after view for all update/change transactions, the user making the change and the date/timestamp. This information must be readily viewable without the need to run an Ad-Hoc report.

C

B.1.41 The System must provide a web-based user interface that supports state, county, and local partner users.

C

B.1.42 The System must meet W3C web accessibility guidelines and comply with Americans with Disabilities Act standards including section 508.

C





OptionRequires

DevelopmentB.1.43 The System must be compatible with assistive technology

products, including screen readers, screen enlargement viewers, and text to speech products.

C

B.1.44 For WIOA, Title I and other programs, the system must provide documentation imaging with the ability to upload documents that can be used for various programs.

C

B.1.45 The System must have the ability to have various user roles and privileges with hierarchy, including the ability to mark cases confidential.

C

B.1.46 The system must provide complete periodic transfers of all Ohio data to a general-purpose ad-hoc reporting environment. This interface supports the ability for ODJFS to have visibility to the activities and events and allows cross reference with Ohio data from other systems.

C

B.2 Technology Driven CapabilitiesB.2.1 The System must have dashboards to help manage outcome

and performance measures.C

B.2.2 The System must provide caseload view for staff and supervisors.

C

B.2.3 The System must set specific program business rules to include program checks and balances to reduce errors.

C

B.2.4 The System must provide prompts to notify alerts and triggers.

C

B.2.5 The System must have the ability to track workload and staff performance based on staff ID/program.

C

B.2.6 The System must support a common intake data feed from OMJ with logic to filter down to eligibility across programs.

C

B.3 Flexibility & Automation CapabilitiesB.3.1 The System must support automated forms available for

electronic customer signature.C





OptionRequires

DevelopmentB.3.2 The System must support documentation imaging with the

ability to upload documents that can be used for various programs.

C

B.3.3 The System must have the ability to automate and prepopulate fields to avoid double entry.

C

B.3.4 The System must have the ability for the State to enter their own unique questions and data fields (i.e.-assessment, eligibility).

C

B.3.5 The System must have the ability for staff to modify sections (by roles - Admin, Supv, Staff); different capabilities.

C

B.4 Program Management CapabilitiesB.4.1 The System must be able to perform all aspects of program

administration (e.g. implementation, evaluation) in full compliance with federal mandates for at a minimum the following federal primary programs by the implementation date: Title 1 Wagner-Peyser related programs:

Labor Exchange;Veterans;Migrant Seasonal Farm Workers (MSFW);Foreign Labor Certification;Re-Entry (REO); andReemployment Services and Eligibility Assessment (RESEA).

Workforce Innovation Opportunity Act (WIOA) Adult and Dislocated Worker.

WIOA Special Grants. WIOA Youth Comprehensive. Rapid Response.

C

B.4.2 The System must support program integration and alignment between WIOA and Title I programs wherever possible.

C





OptionRequires

DevelopmentB.4.3 The System must support other federal primary programs or

enhancements due to Ohio legislative mandates, or workforce federal mandates that occur during the project development lifecycle; e.g. mandated changes to PIRL report.

C

B.4.4 The System must have the ability to add, modify, inactivate and delete other primary programs.

C

B.4.5 The System must provide other primary programs access to all available System capabilities, functions and controls.

C

B.4.6 The System must be able to provide the same type of regulatory and operational reporting for other primary programs available to primary programs (e.g. Wagner-Peyser, WIOA).

C

B.4.7 The System intake process for other primary programs must be able to utilize the same intake process for federal primary programs.

C

B.4.8 The System must be able to perform all aspects of required federal reporting for all federal programs implemented as a part of this project for compliance with common performance measures.

C

B.4.9 The System must have the ability to add, modify and delete sub programs within an existing primary program. The available data elements must be the same as the primary program.

C

B.4.10 Sub programs must have access to the same integrated System capabilities, functions and controls as the primary program.

C

B.4.11 The System must be able to provide the same type of regulatory and operational reporting for sub programs as that of the primary program. The System must also be able to provide combined reporting of the primary and sub program.

C





OptionRequires

DevelopmentB.4.12 The System must perform all aspects of program

administration (e.g. implementation, performance) for State funded programs as prescribed at the State Level.

C

B.4.13 The System must have the ability to implement mandated requirements from State funded programs or legislation, including but not limited to Ohio House Bill 2 of 2013: https://legiscan.com/OH/bill/HB2/2013.

C

B.4.14 The System must have the ability to add, modify and delete State programs.

C

B.4.15 The System must be able to perform all aspects of required State reporting for all State programs and legislation implemented within OWST by the implementation date.

C

B.4.16 The System must be able to implement Local funded programs as prescribed at the Local Area, County and/or at the Local Partner Level.

D

B.4.17 The System must be able to perform all aspects of required Local Area, County and/or Local Partner Level reporting for this level of programs implemented within OWST by the implementation date.

D





OptionRequires

Development

B.5 OhioMeansJobs.com (OMJ) Integration

Employers may post a job order for free and register to search resumes. Job seekers may post a resume, so employers can find eligible candidates; search for job openings, internships, and apprenticeships; view job fairs; and register for workshops.

Ohio Means Jobs is Ohio's online career & employment system where it allows employers to post their job openings and search for potential candidates. It’s also used to help our job seekers find employment and learn about the in-demand occupation for their area. OMJ is mandatory system that must have the ability to interface with the new case management system to allow the information to be pulled over into the system of record. B.5.1 The System must have a bi-directional interface with

OhioMeansJobs.com, Ohio’s mandated system (OMJ), to request and load both job seeker and employer data.

C

B.5.2 The System must provide a real-time interface from OMJ for Common Intake data, where job seekers register in OMJ through a common registration to OWST.

C

B.5.3 The System must automatically create a basic intake record with data, including but not limited to, name, address, date of birth and social security number.

C

B.5.4 The System must manage synchronization of new seeker or update existing seeker record.

C

B.5.5 The System must provide at least an every 4-hour feed from OMJ for additional seeker information (not included in the basic intake record interface) to include job seeker data, assigned activities, job search data, assessments, resume, and career profile scores must be at least a daily feed from OhioMeansJobs to OWST.

C





OptionRequires

DevelopmentB.5.6 The System roadmap must provide a plan for near real time

updates. Additional seeker information (not included in the basic intake record interface) must include job seeker data, assigned activities, job search data, assessments, resume, and career profile scores.

C

B.5.7 The System must provide at least a daily feed from OMJ for all remaining employer and business data that includes individual’s registration data (re-entry participants), self-service data, job order data, and services to OWST.

C

B.5.8 The System must provide a real time feed of job seeker activity/services data to OhioMeansJobs.

C

B.6 Comprehensive Assessment and Services B.6.1 The System must have a Case Management module that

enables case management of individual job seekers eligible for services in federal and/or state programs.

C

B.6.2 The System must have Case Management capabilities for workforce professional case workers and their supervisors, including but not limited to, case assignment and re-assignment, separate work queues, case searches, and tracking and reporting of seeker activities and services.

C

B.6.3 The System must have the ability to have primary and multiple secondary case workers assigned to the same seeker. Tracking and reporting of seeker activities and services must be tied to the correct case manager and all activities/services must roll up to the primary case manager.

Example of multiple case managers assigned may include a WIOA case manager, a Special Grants case manager, and a Trade case manager on the WIOA side for the same individual. Another example may be a Title 1 Labor Exchange side Case Manager and a Veterans Case Manager for the same individual.

C





OptionRequires

DevelopmentB.6.4 The System must provide at a minimum separate work

queues for the petitions, service delivery, and contract staff. C

B.6.5 The System must provide the ability to track case worker assignments and performance based on unique identifier, e.g. staff ID and by program.

C

B.6.6 The System must have the ability to store and present sensitive information under a program (e.g. domestic violence, substance abuse, etc.) and limit read/update access only to authorized case managers and their supervisors.

C

B.6.7 The System must provide the case manager productivity tools (e.g. reminders, my cases summary view, etc.). This must include the reminders for follow-up and other required case manager actions.

C

B.6.8 The System must have the capability to add/update/delete job seeker information.

C

B.6.9 The System must allow for a common assessment and career planning that help guide career pathways to employment (e.g. Comprehensive assessment, IEP, TABE).

C

B.6.10 The System must provide access to all elements for seeker assessment and ability to link and document results of self-service assessment instruments. This must include formalized assessments such as TABE, CASS, and WorkKeys. This must include the ability to enter multiple test results and track progress of participants with the ability to identify skill gains.

C

B.6.11 The System must provide for seeker tracking mechanisms, individual service plans, individual opportunity plans, and tracking of services.

C

B.6.12 The System must provide the ability for follow up activities for all programs including identification of mandated (e.g. 1 year, follow up) activities.

C





OptionRequires

DevelopmentB.6.13 The System must provide configurable alerts, including but

not limited to, 30/60/90 day follow up, no service provided and/or no activity.

C

B.6.14 The System must have the ability to track TANF certification and eligibility as needed.

C

B.6.15 The System must have the ability to track hours for seekers who are TANF work required and validate them weekly according to federal and state guidelines.

C

B.7 Case Intake and Eligibility

B.7.1 The System must provide the ability for internal users to register job seekers, determine eligibility, and certify for all implemented programs across WIOA, Title I, state and other mandated programs.

C

B.7.2 The System must complement the OhioMeansJobs.com common intake process by leveraging all data available with the bi-directional OMJ interface and one-way for other systems of record that provide job seeker data.

C

B.7.3 The System must provide state, county, and local partners the ability to register job seekers to include, but not be limited to, biographical, demographic and geographic data, and military information (same as OMJ).

C

B.7.4 The System must provide an automated solution to identify eligibility across multiple programs and allow for dual enrollment where appropriate.

C





OptionRequires

DevelopmentB.7.5 The System must provide the ability for, but not be limited

to, eligibility determinations for the following programs: Title I (Adult, Dislocated Worker, and Youth); Optional: Title II (Adult, Education, and Family

Literacy Act) ABLE; Title III (Employment Services – Veterans, Labor

Exchange, Apprenticeship); Optional: Title IV (Vocational Rehabilitation); and Optional: Ohio Family Assistance (SNAP, TANF,

OWF, CCMEP).

C

B.7.6 The System must provide for participant eligibility determinations with all data elements as required by the federally sponsored Workforce Innovation Opportunity Act.

C

B.8 Training Providers

An education & training tracking system that identifies eligible training providers and programs that are qualified to receive WIOA Title I funds in order to train WIOA job seekers.

B.8.1 The System must have the ability to designate, annual renewal, appeal, store and track information on Eligible Training Providers, including but not limited to, provider profile, training program, professional certification/designation and performance data.

C

B.8.2 The System must fully integrate the training provider module with case management.

C

B.8.3 The System must have a real time feed from the system of record to the Workforce Inventory Education & Training (WIET) system which tracks eligible training providers and programs.

C

B.8.4 The System must have a real time feed from the Workforce Inventory Education & Training (WIET) system to OWST for Title 1 and WIOA programs and sub-programs.

C





OptionRequires

DevelopmentB.8.5 The System must have a real time feed (two ways) from the

case management system to the Workforce Inventory Education & Training (WIET) system which tracks eligible training providers and programs).

C

B.8.6 The System must have the ability to pull in WIET training providers/program data into the case management system (Individual Training Account).

C

B.8.7 The System must have the ability to identify and track providers at a local and state level.

C

B.8.8 The System must have the ability for provider to register their training institution (demographics and pertinent Ohio based standards/criteria and performance measures).

C

B.8.9 The System must have the ability for providers to enter program data.

C

B.8.10 The System must have the ability for the providers to appeal (provider data, program data, performance).

C

B.9 Employer ServicesB.9.1 The System must interface with the OhioMeansJobs.com

feature that provides an Employer Management component which is responsible for employer registration, follow up with employers, and their recruitment needs.

C

B.9.2 The System must provide the ability for state, county, and local partners to input and view information about employers, job orders, and services provided.

C

B.9.3 The System must receive Employer authentication information from OMJ's authentication process and use their unique employer identifier to identify records and services provided to that employer.

C





OptionRequires

DevelopmentB.9.4 The System must have employer contact management

capabilities, including but not limited to, maintaining a list of businesses, profile data, their contacts and representatives, reduction in force data, and a contact history log to record interactions.

C

B.9.5 The System must provide authorized staff the ability to access all employer records to provide assistance and monitoring.

C

B.9.6 The System must provide the ability to assign and track lead staff contacts to each employer record.

C

B.9.7 The System must provide the ability to track predetermined services provided to each employer including on-site visits, job fair participation, on the job contracts, general recruitment assistance, rapid response, interview scheduling, labor market information given, etc.

C

B.10 Fiscal ManagementB.10.1 The System must have the ability to track and report

financial information for implemented programs. This includes, but is not limited to, total budget and amount spent year-to-date by budget line item within program, region and local office.

C

B.10.2 The System must have the ability to track and report financial information for vendors.

C

B.10.3 The System must have the ability to limit, track and manage financial information for an individual, and facilitate processing of training invoices.

C





OptionRequires

DevelopmentB.10.4 The System must provide a real-time interface from OWST

to the County Finance Information System (CFIS) for Title 1 and WIOA programs and sub-programs to include registered clients in the OMJ Center and services provided during the eligibility and enrollment process. CFIS is a financial system utilized by Ohio to link workforce services in the case management system to expenditures. This system tracks financial data back to the counties and their budgets against WIOA federal guidelines for the distribution of funds.

C

B.10.5 The System must provide the ability to select multiple funding sources per service.

C

B.11 Communication, Forms and NoticesB.11.1 The System must have the ability to schedule and track

appointments and/or provide an intuitive calendar option.C

B.11.2 The System must have the ability for referrals with alerts from program to program (example: Trade to LE or LE to WIOA) which alerts staff.

C

B.11.3 The System must have the ability for referrals from local area to local area/local partner and/or county to county which alerts staff.

C

B.11.4 The System must provide e-mail functionality. CB.11.5 The System must provide the ability for an authorized

person to define broadcast messages that can be delivered to all users or a subset of users upon log-in and/or when specified screens are displayed.

C

B.11.6 The System must provide a feed to the State of Ohio print shop to generate and mail correspondence to individuals, training providers, and employers for various programs, e.g. RESEA, CCMEP.

C





OptionRequires

DevelopmentB.11.7 The System must provide robust case notes functions,

including case note templates and spellcheck.C

B.11.8 The System must allow staff to administer (add/modify/delete) notes to a participant’s or employer's record.

C

B.11.9 The System must create notes automatically based on system and OWD program business rules. These notes must be uniquely identified as ‘system generated’ notes.

C

B.11.10 The System must provide the ability for private and public case notes.

C

B.11.11 The System must have the ability to integrate our paper forms with our case management system that allow for electronic customer signature/print/and save functionality.

C

B.11.12 The System must have the ability to build electronic forms that can be integrated back to the system of record.

C

B.12 ReportingB.12.1 The Reporting Module must have an Ad-Hoc Reporting

component enabling authorized staff to produce ad-hoc reports based on comprehensive data sets, such as date ranges, federal program, state program, participant barriers, selectable data fields, performance by year and quarter, etc.

C

B.12.2 The Reporting Module must have the ability to create Ad-Hoc reports by Workforce Investment Board (local area), state, and provider level for all implemented programs.

C

B.12.3 The Reporting Module must allow a state and/or local system administrator to schedule an Ad-Hoc report to automatically run in the future based upon date/frequency parameters without requiring coding changes or the need to re-write a query.

C

B.12.4 The Reporting Module must produce both on-demand and regularly scheduled reports.

C





OptionRequires

DevelopmentB.12.5 The Reporting Module must provide the ability to track

performance measures at the participant level and aggregate, track services to participants and employers including the ability to pull individual case management reports based on performance measures.

C

B.12.6 The System must be able to develop, and store reports based upon information on job seekers, including but not limited to, (1) demographic information, work experience, education, skills, type of job desired and location, (2) O*NET codes for jobs desired, and (3) services provided by staff and/or service providers.

C

B.12.7 The Reporting Module must provide robust filter and sort options by criteria such as case manager, local partner, Workforce Investment Area, county, activity, funding source, etc.

C

B.12.8 The Reporting Module must have the ability to generate the PIRL, Participant Individual Record Layout and associated data files for submission to the U.S. Department of Labor. Describe the reporting system’s compliance status as of today with WIOA data standards in relation to the PIRL.

C

B.12.9 The Reporting Module must have the ability to generate test reports to verify results prior to submission of required federal reporting for all mandated programs in accordance with Common Measures. Authorized users must have the ability to run these reports on an as needed basis.

C

B.12.10 The Reporting Module must provide standard WIOA and Title I federal mandated reports (all Titles, Veterans, etc.).

C





OptionRequires

DevelopmentB.12.11 The Reporting Module must be able to generate local/state

reports on job seekers and employers by geographic area (Statewide, Workforce Investment Area, county/city, or OMJ Center), by staff, or by case manager, service provider, geographic area, industry and different demographics. This includes, but is not limited to, reporting on outcomes, numbers served/exited, services provided, demographics of persons served/exited and outcomes, pending/actual exits, employers served, etc.

Provide a listing and short description of all current automated state reports requested, created and shared by current state clients.

C

B.12.12 The Reporting System must serve as the single repository and data source for all program reporting purposes. The system will extract, transfer and load data from multiple sources for reporting purposes identified in other sections within this supplement.

C

B.12.13 The System must be able to develop, and store reports based upon information on employers, including but not limited to, (1) industry category by the North American Industry Classification System (NAICS), (2) by Standard Occupational Classification (SOC), location and contact information, and (3) services provided by workforce development staff to employers.

C

B.12.14 The System must allow staff to access available reports to run via a variety of methods (displayed list of available reports, ability to search for a specific report or type of report, etc.).

C

B.12.15 The System must allow staff to run parameterized on-demand reports.

C

B.12.16 The System must allow staff to maintain a run-time schedule for reports.

C





OptionRequires

DevelopmentB.12.17 The System must produce reports based on staff defined

intervals (daily, weekly, monthly, etc.).C

B.12.18 The System must allow staff to select the delivery method for available reports.

C

B.12.19 The System must allow staff to pre-define the number of records to be returned per page on a report.

C

B.12.20 The System must provide logical navigation for multi-page reports.

C

B.12.21 The System must allow staff to retrieve on-demand reports real time or in overnight batch mode.

C

B.12.22 The System must regulate the production of on demand report based on system usage/performance.

C

B.12.23 The System must notify staff when an on-demand report is available when the generation of the report was delayed due to system usage/performance.

C

B.12.24 The System must automatically route report results to staff (both regularly scheduled reports and on-demand reports).

C

B.12.25 The System must display reports in multiple formats (i.e. table, chart, graph).

C

B.12.26 The System must allow staff to save reports in various formats including XLS, DOC, PDF, CSV, TXT, and Image files.

C

B.12.27 The System must provide a printable view of reports (with no truncating report data).

C

B.12.28 The System must archive reports. CB.12.29 The System must have an adhoc reporting tool that can

export to Excel for case load and performance reporting at all levels to include: local, state, provider, and all workforce areas.

C

B.12.30 The System must have the ability to customize each report based on all the data fields, performance year/quarter, and date range.

C





OptionRequires

DevelopmentB.12.31 The System must have the ability to create ad hoc reporting

by Workforce Investment Board, State, and provider level.C

B.12.32 The system must have the ability to track, monitor, and report on common performance measure to ensure compliance.

C

B.12.33 The system must have the ability to create/integrate reports across all Title I and Title 3 Programs.

C

B.13 UsabilityB.13.1 The System’s user interface must be designed in a manner

consistent with current web development and user experience standards such as multiple navigation methods, drop-down fields, allowing for textual input in business terms rather than codes, etc.

C

B.13.2 The System must contain an integrated on-line trouble-shooting facility inclusive of all common errors and probable resolutions.

C

B.13.3 The System must support multiple navigation controls (e.g. menu, icons, keyboard shortcuts, right-click).

C

B.13.4 The System must support hover-over controls to display functional descriptions and context-sensitive help.

C

B.13.5 The System must support the ability to automate and prepopulate fields to decrease duplicative staff entries.

C

B.13.6 The System’s user interface must be an intuitive design which guides the user through implemented programs’ requirements/business rules to reduce error and maintain consistency.

C

B.13.7 The System must provide real-time integration of common data (i.e. biographical/demographic) for all implemented programs in order to eliminate redundant data entry.

C





OptionRequires

Development

B.14 System AdministrationB.14.1 The System must be table/rules driven and have the

capability and tools for authorized users to interactively add/update/delete table values, rules, screens, data elements, forms, letters, notifications, etc. without generally requiring code changes.

C

B.14.2 The System must support role-based authentication and allow authorized users to manage roles and user profiles on-line.

C

B.14.3 The System must have the capability and tools for authorized users to make changes to branding and add/modify/delete web content without generally requiring code changes.

C

B.14.4 The System must have the capability of allowing the State to enter their own unique questions and data fields (i.e.-assessment, eligibility).

C

B.15 County Data IntegrationB.15.1 For implemented programs and sub-programs for WIOA,

Title I and other mandated programs, the System must provide the ability for daily uploads from Ohio Counties (contains demographics, services of registered individuals).

C

B.15.2 For implemented programs and sub-programs for WIOA, Title I and other mandated programs, the System must provide the ability to upload data to the case management system from Ohio's various 88 counties unique systems.

C

B.15.3 For implemented programs and sub-programs for WIOA, Title I and other mandated programs, the System must provide the ability to accept basic intake and basic demographic data via internal and/or external data sharing uploads.

C


7 Table C: Interfaces

Requirement Type definitions: C is a critical component of the system. D is a desirable component of the system.

OWST InterfacesType Offeror Response



OptionRequires

Development

C.1 Interfaces C.1.1 The System must support real time and/or batch data

exchange with other Job and Family Services systems (e.g. Unemployment Insurance, Ohio Benefits for SNAP/TANF, SETS for child support, and Ohio Job Information).

C

C.1.2 The System must provide an interface with the Ohio Unemployment Insurance (UI) system to provide a bi-directional flow of information to synchronize the transfer of necessary data like UI wage data, claimant occupational codes, etc. for program participants, between the two systems.

C

C.1.3 The System must support real time feed/Nightly file with UI System of Record that includes unemployment claimant data, including RESEA per individual.

C

C.1.4 The System must be able to interface with the Ohio UI system to provide Trade Readjustment Allowances (TRA) data which may reside in Ohio’s UI system. Since receipt of TRA extends the period of participation or delays program exit, a claimant’s status must be kept active in the System in accordance with federal requirements.

C





OptionRequires

DevelopmentC.1.5 The System must be able to interface with the Ohio UI

system to update the number of claimants it is capable of servicing. The interface must (1) provide information necessary to produce the quarterly ETA 9048 report (including number of claimants provided with re-employment services), (2) generate the quarterly ETA 9049 report which includes the employment outcomes of claimants referred to re-employment services, and (3) notify the appropriate UI claims office of any claimant who fails to report or participate in re-employment services, unless the claimant completed those services previously.

C

C.1.6 The System must support real time data exchange with external systems (e.g. other state agencies, federal government, vendors).

C

C.1.7 The System must provide an electronic interface with occupational coding software.

C

C.1.8 The System must provide a real time and/or batch data exchange with the Ohio Department of Medicaid Ohio Benefits system to receive updated program information (e.g. status of benefits, etc.), update a participant’s record, etc.

C

C.1.9 The System must have the ability to accept UI Operations System of Record Interface-Data real time; Job Leads- ability to send job leads to UI participants; Re-employment Program- RESEA.

C

C.1.10 The System must interface with America's Labor Market Information (ALMIS) Database, InfoUSA's ALMIS Employer Database and other sources of labor market data.

C

C.1.11 The System must provide address and/or zip code verification via interface with a service or USPS.

C

C.1.12 The System must provide an electronic interface with Ohio Department of Administrative Services for printing/mailing services.

C





OptionRequires

DevelopmentC.1.13 The System must support data feeds/interfaces to prepopulate

fields in the case management system. Ohio will work with the provider to determine these fields or what data will be used and stored in the tables.

C

C.1.14 The System must have a real time feed from OhioMeansJobs (OMJ) of registered Job Seekers and to create job posts.

C

C.1.15 The System must support a nightly file from Ohio Benefits (Adult SNAP TANF) which is the system of record for the Health and Human Services programs (Supplemental Nutrition Assistance Programs and Temporary Assistance for Needy Families) to register new participants.

C

C.1.16 The System must support a real time feed and nightly file with Ohio UI System that includes unemployment claimant data, including RESEA per individual.

C

C.1.17 The System must support daily Uploads from Ohio Counties (contains demographics, services of registered individuals).

C

C.1.18 The System must support real time data feeds (every 4 hrs.) from OhioMeansJobs that include individual’s registration data (re-entry participants), self-service data, job order data, and services.

C

C.1.19 The System must provide a real time feed from the Workforce Inventory Education & Training (WIET) system.

C

C.1.20 The System must provide a real time feed from the County Finance Information System (CFIS).

C

C.1.21 The System must provide a real time feed/nightly file with ERIC for wage information.

C

C.1.22 The System must interface with the U.S. Veterans Affairs information to automatically validate the veteran target group. (WOTC option).

C

C.1.23 The System must interface with the Opportunities for Ohioans database to validate voc rehab target group. (WOTC option)

C





OptionRequires

DevelopmentC.1.24 The System must interface with the WOTC address locator to

automatically validate eligibility for WOTC designated target groups. (WOTC option)

C

C.1.25 The System must interface with Maximus Ticket to Work system to validate eligibility for WOTC. (WOTC Option)

C

C.1.26 The System must interface with Ohio Department of Corrections to validate eligibility.

C

C.1.27 The System must provide daily feed to OAKS or CFIS that includes information to make payment to providers, employers or other entities.

C

C.1.28 The System must provide a feed to the Office of the Attorney General that includes information concerning certified debt for collection.

C

C.1.29 The System must provide a daily feed to the Treasurer of State that includes warrant information required to pay benefits to individuals.

C

C.1.30 The System must provide a quarterly feed to Alda (Ohio State University longitudinal database).

C

C.1.31 The System must provide a real time feed from the Ohio Child Support System (SETS).

C

C.1.32 The System must have the ability to identify and report potential issues, negative outcomes, which may be the basis for disqualification from UI benefits. Often referred to as ‘negative reporting’. These situations include, but are not limited to, failure to apply for job referrals, failure to accept work offered and failure to report to job interviews and other reemployment activities.

C

C.2 Interface InteroperabilityC.2.1 The System must automatically export data from the system

in multiple formats (e.g., csv, fixed length ASCII, tab delimited).

C





OptionRequires

DevelopmentC.2.2 The System must automatically import data into the system in

multiple formats (e.g., csv, fixed length ASCII, tab delimited).

C

C.2.3 The System must automatically maintain external system information for interfaces (e.g., connection strings, file paths).

C

C.2.4 The System must automatically transmit/receive imported/exported data through multiple methods (e.g., file output, web service, single and batch transactional (e.g., PIRL).

C

C.2.5 The System must automatically generate and execute scripts to import and export data.

C

C.2.6 The System must automatically present a result list for data imports and exports (e.g., success or failure, time started, time completed).

C

C.2.7 The System must automatically report on interface transmissions (e.g., total number of records loaded, date of interface transmission, amount of time to execute the interface transmission, errors, and failures).

C

C.2.8 The System must automatically isolate records within a file that contain an error condition and process the file excluding the error records.

C

C.2.9 The System must automatically create a report of records that could be successfully processed within a batch file.

C

C.2.10 The System must automatically restart an interface transmission from a specific point (e.g., restart at failed record, restart from beginning).

C

C.2.11 The System must automatically associate information received via interface with the line-of-business record which generated the information request.

C

C.2.12 The System must maintain interfaces into current state Systems in the format and frequency approved by ODJFS, including batch transactions that have the ability to create a log with job errors and schedule jobs and run jobs on-demand.

C


9 Table D: Common RequirementsRequirements Type definitions: C is a critical component of the system. D is a desirable component of the system.

Common System RequirementsType Offeror Response



OptionRequires

Development

D.1 Security and RecoveryD.1.1 Application access must be logged and have a viewable audit

trail(s). C

D.1.2 Changes to user permissions must be logged and have a viewable audit trail(s).

C

D.1.3 Access to audit trail logs must be able to be restricted to approved administrators.

C

D.1.4 Application access and changes to application access must log the following information: Date/time; Nature of operation; Name of changed item; Name of who made the change; and Before and after value of the changed item.

C

D.1.5 The following application change event(s) must be logged: Changes to individual permission level; Changes to role membership; Changes to role permissions; and Changes to access to application functions.

C

D.1.6 The System Administrator must be able to control access to audit trail logs.

C





OptionRequires

DevelopmentD.1.7 Passwords and User IDs must be able to:

Protect sensitive data; Restrict access to only those intended; Meet Federal/State/Agency Security Standards; and Be able to be encrypted.

C

D.1.8 Applications and systems must adhere to ODJFS Policy regarding Access to Networks, Systems, Computers, Databases and Applications.

C

D.1.9 Applications and systems must adhere to ODJFS Policy regarding Access to Protected Data Resources.

C

D.1.10 End-user software applications, or components thereof, must not require privileged, super-user or administrator mode in order to function properly.

C

D.2 Identity ManagementD.2.1 The System authentication and authorization must be by

individual user. User account information must be stored securely. Users may belong to groups and roles.

C

D.2.2 The System must provide the system administrators with the capabilities to define different roles with different privileges.

C

D.2.3 The System must provide for hierarchical roles. C

D.3 System Performance and CapacityD.3.1 The system must provide performance-optimization

capabilities. C

D.3.2 The System must provide a response time of less than 2 seconds for accessing low complexity pages composed of mostly static text and other non-computationally intensive elements.

C

D.3.3 The System must provide a response time of less than 5 seconds for accessing medium complexity pages composed of some static text along with dynamic text related to a single entity retrieved from the database.

C





OptionRequires

DevelopmentD.3.4 The System must provide a response time of less than 5

seconds for 90% of all searches. The remaining 10% must complete in less than 15 seconds.

C

D.3.5 The System must provide a response time of less than 15 seconds for accessing any level of complexity pages composed of dynamically generated text, images, multimedia elements, many computationally intensive elements, and calls to external, non-cacheable services.

C

D.3.6 The System must support 300 simultaneous staff users with an average of 15 seconds think time between page requests.

C

D.3.7 The System must support 1 million participant records per year.

C

D.3.8 The System must maintain 10 years of participant and employer history.

C

D.4 HostingD.4.1 A documented Physical and Environmental protection

policy that addresses purpose scope, roles, responsibilities, and procedures developed and distributed to all employees, must be provided.

C

D.4.2 The proposed solution delivers standard reports/information useful for assessing the overall status, operation and debugging of the solution.

C

D.5 Single Sign-onD.5.1 The System must support single sign-on for all functions

within the System (e.g. staff must not have to separately logon to conduct case management and job matching functions).

C

D.5.2 The system must address the requirements in supplement 3. C





OptionRequires

Development

D.6 Work FlowD.6.1 The System must automatically distribute work items to the

appropriate staff using staff's profile and configurable work item attributes.

C

D.6.2 The System must automatically start and stop the distribution of work items when the configurable limits for a work type are reached in the staff's inbox.

C

D.6.3 The System must allow staff to adjust the distribution of work items.

C

D.6.4 The System must allow staff to search, select, and assign selected work items to a staff inbox.

C

D.6.5 The System must allow staff to view work items distributed by team, role, area and staff members.

C

D.6.6 The System must automatically alert staff when a work item is approaching or past the work item's due date of completion.

C

D.6.7 The System must allow staff to search for work items using single or multiple search criteria.

C

D.6.8 The System must allow staff to limit the number of results returned for a work item search.

C

D.6.9 The System must automatically display the results of a search for work items.

C

D.6.10 The System must automatically display the search criteria used for the image/work item search on the search result screen.

C

D.6.11 The System must allow staff to select a work item or multiple work items to perform a selected action.

C

D.6.12 The System must allow staff to add, edit and delete notes to an image or work item.

C

D.6.13 The System must automatically update the status of a work item each time an action is taken on the work item.

C





OptionRequires

DevelopmentD.6.14 The System must automatically distribute work items

requiring approval to designated staff. C

D.7 Help SearchD.7.1 The System must provide context sensitive, on-demand help. CD.7.2 The System must provide immediate, searchable and

relevant on-line access to all Workforce Development policy and procedure manuals and new updates.

C

D.7.3 The System must provide an online general subject index, process and procedure guide and field-level help guide.

C

D.7.4 The System must provide a full glossary of all Workforce Development terms.

C

D.7.5 The System must allow staff to perform online searches using a variety of parameters (text, dates, etc.).

C

D.7.6 The System must allow staff to perform keyword searches. CD.7.7 The System must allow staff to combine multiple search

criteria using logical operators such as ‘AND’, ‘OR’, BETWEEN’ and 'LIKE'.

C

D.7.8 The System must allow staff to sort search results returned data.

C

D.7.9 The System must allow staff to filter search results. CD.7.10 The System must allow staff to search and retrieve records

(or logical groups of records) matching compound search criteria.

C

D.7.11 The System must provide query searching capabilities that can be used to search within a result set.

C

D.7.12 The System must allow staff to perform advanced searches to filter search results.

C

D.7.13 The System must allow staff to configure the number of returned search results.

C





OptionRequires

Development

D.8 Security User Interface D.8.1 The System must enforce security roles at a function level to

determine users (internal/external) ability to enter, update, view and/or delete.

C

D.8.2 The System must provide the ability for state staff, county case workers, and local partners to logout of the system/web account on all screens/pages.

C

D.8.3 The System must allow staff to establish "user profiles" consisting of one or more security roles from which individual staff may inherit privileges.

C

D.8.4 The System must automatically log security events (e.g., failed/successful login attempts, amendment of user rights, inactivation of users).

C

D.8.5 The System must automatically log staff accessing confidential personal information.

C

D.8.6 The System must have a consistent look and feel for all web enabled user interfaces (for staff, employers/TPAs and claimants) and abide by agency branding standards.

C

D.8.7 The System must provide logical navigation and menuing for each screen.

C

D.8.8 The System must be flexible with dynamic displays of information, data capture, edits/validations, instructional messages etc. based on security roles.

C

D.8.9 The System must pre-populate data on screens (eliminate redundant/duplicate data entry).

C

D.8.10 The System must allow the ability for staff to navigate between related functionality within a line of-business record without re-entering the original search criteria.

C

D.8.11 The System must automatically display a progress indicator to users for all processes requiring multiple steps or screens.

C

D.8.12 The System must automatically display a time-out indicator to users prior to timing them out of system.

C





OptionRequires

DevelopmentD.8.13 The System must adhere to all Agency and State security

policies and procedures.C

D.8.14 The System must be capable of offering historical tracking features when critical business information is modified so it can be referenced for future use.

C

D.8.15 The system must be capable of archiving data for retention, then purge data according to federal mandate and/or Office of Workforce Development established retention schedule.

C

D.9 General D.9.1 Must provide testing and training environments which are

routinely updated with functionality additions and fixes that reflect the most current version of solution.

C


10 Table E: Program Specific Requirements

Program Services RequirementsThe following section depicts program specific requirements and provides program specific capabilities which supplements the above Table B: OWST Business Requirements.

Type Offeror ResponseCheck Applicable Box Narrative

Core Capability

Configuration Option

Requires Development

E.1 WIOA Adult and Dislocated Workers.

The system must follow the mandated federal requirement by the Department of Labor (DOL) for the Workforce Innovation and Opportunities Act (WIOA). WIOA was designed to provide quality employment and training services to help eligible adults and dislocated workers to find and qualify for meaningful careers. Therefore, the system must have a way to determine eligibility, track basic services, individualized career services, training, and 12 months of follow up in order to meet DOL's requirements. See the common criteria section for additional Program Requirements. Mandated by Federal Law: www.doleta.gov/WIOA/Final_Rules_Resources.cfm.

E.1.1 The System must offer a robust adult and dislocated eligibility system that determines eligibility for TANF and WIOA and has the flexibility to track customer eligibility changes as well as any changes in policy.

C

E.1.2 The System must have the ability to view program progress in the form of a dashboard-visual representation by county of program results.

C

E.1.3 The System must have the ability to select multiple funding sources per paid service.

C

E.1.4 The System must have the ability to upload certified worker data in multiple formats (.xls, .csv, etc.) into the case management system (system of record).

C


http://www.doleta.gov/WIOA/Final_Rules_Resources.cfm



Core Capability



E.1.6 The System must have the functionality for Case Management to update the Employment Plan in order to track required services and to assist in guiding career pathways to employment.

C

E.1.7 The System must have the ability to capture and offer eligibility, dual enrollment, track and monitor required services, job placements and 12 months of follow up.

C

E.1.8 The System must process the nightly file from Ohio Benefits (Adult SNAP and TANF) which is the system of record for the Health and Human Services programs (Supplemental Nutrition Assistance Programs and Temporary Assistance for Needy Families) accepting new program participants.

C

E.1.9 The System must have data feeds/interfaces to prepopulate fields in the case management system. Ohio will work with the provider to determine these fields or what data will be used and stored in the tables.

C

E.1.10 The System must support a real time feed from OhioMeansJobs (OMJ) of registered Job Seekers.

C

E.1.11 The System must have daily uploads from Ohio Counties (contains demographics, services of registered individuals).

C

E.1.12 The System must support data feeds (every 4 hrs.) from OhioMeansJobs that includes individual’s registration data (re-entry participants), self-service data, job order data, and services.

C

E.1.13 The System must support a real-time data feed from OhioMeansJobs that includes individual’s registration data (re-entry participants), self-service data, job order data, and services.

D

E.1.14 The System must have a real time feed from the Workforce Inventory Education & Training (WIET) system.

C




Core Capability



E.2 WIOA Youth Program (CCMEP)

CCMEP is a WIOA Youth employment and training program that helps low income customers between the ages of 14 to 24 years old's who are registered in the WIOA program. What is unique to Ohio is the CCMEP program integrates both the WIOA program and the Temporary Assistance for Needy Families (TANF) program to offer more coordinated and individualized services. The system must have the ability to offer a robust eligibility system, track a variety of participating services, have the ability to determine eligibility for two programs, and the flexibility to track customer eligibility changes on a case by case basis.

Mandated by Federal Law www.doleta.gov/WIOA/Final_Rules_Resources.cfm, and Ohio Administrative Code: http://codes.ohio.gov/oac/5101:14

Mandated by State Law

http://codes.ohio.gov/oac/5101:14- Comprehensive Case Management Program (WIOA Youth)

See the common criteria section for additional Program RequirementsE.2.1 The System must offer a robust youth eligibility system that

determines eligibility for TANF and WIOA and has the flexibility to track customer eligibility changes as well as any changes in policy.

C

E.2.2 The System must provide the ability to view program progress in the form of a dashboard-visual representation by county of program results.

C


http://codes.ohio.gov/oac/5101:14



Core Capability



E.2.3 The System must have the functionality for Case Management to update the Employment Plan in order to track required services and to assist in guiding career pathways to employment.

C

E.2.4 The System must have the ability to dual enroll customers in multiple programs with the ability to view all programs.

C

E.2.5 The System must have the ability to select multiple funding sources per paid service.

C

E.2.6 The System must have the ability to track hours for customers who are TANF work required and validate them weekly.

C

E.2.7 The System must have the ability to upload certified worker data in multiple formats (.xls, .csv, etc.) into the case management system (system of record).

C

E.2.8 The system must have the ability to capture and offer eligibility, dual enrollment, track and monitor services, job placements and 12 months of follow up.

C

E.2.9 The System must support a nightly file from Ohio Benefits (Adult SNAP TANF) which is the system of record for the Health and Human Services programs (Supplemental Nutrition Assistance Programs and Temporary Assistance for Needy Families) that registers new participants.

C

E.2.10 The System must support data feeds/interfaces to pre-populate fields in the case management system. Ohio will work with the provider to determine these fields or what data will be used and stored in the tables.

C

E.2.11 The System must have roles with hierarchy to include the ability to mark cases confidential.

C

E.2.12 The System must provide case load view for staff and supervisors.

C

E.2.13 The System must support a real time feed from OhioMeansJobs (OMJ) of registered Job Seekers.

C




Core Capability



E.2.14 The System must support a daily upload from Ohio Counties (contains demographics, services of registered individuals).

C

E.2.15 The System must support a 4-hour data feed from OhioMeansJobs that includes individual’s registration data (re-entry participants), self-service data, job order data, and services.

C

E.2.16 The System must support a real time feed from the Workforce Inventory Education & Training (WIET) system.

C

E.2.17 The System must support a real time feed from the County Finance Information System (CFIS).

C

E.2.18 The System must restrict access to special grant programs to only those the users granted the correct user role.

C

E.3 Rapid Response and Layoff Aversion Responds to plant closings or layoffs with free information about services. Businesses that lay off 50 or more workers are subject to WARN notification rules.

A program to help businesses and workers deal with the effects of layoffs and plant closures, including those that result from increased competition from imports, natural disasters, and other events.

Mandated by Federal Law: https://www.doleta.gov/layoff/rapid.cfm.

E.3.1 The System must connect the RR Employer/Event with each individual in Case Management system to track services and activities through re-employment.

C

E.3.2 The System must have the ability to allow in-state and out of state employers to be listed in the database.

C

E.3.3 The System must be able to retain all WARN details on each company.

C

E.3.4 The System must be able to track services given to WARN companies.

C




Core Capability



E.3.5 The System must have the ability to track by impacted company (i.e. layoffs, closings).

C

E.3.6 The System must be able to obtain a list of affected workers and track from WARN to employment.

C

E.3.7 The System must track customized services on-site at an affected your company, accommodate any work schedules, and assist company leadership and affected workers through the painful transitions associated with job loss.

C

E.3.8 The System must support document scanning and retrieval to accept the Survey notes in the case where they are done via hard copy.

C

E.3.9 The System must provide Veterans Priority of Service. Please describe how your system prioritizes veterans in this context.

C

E.3.10 The System must maintain an Employer Services database to track employer information surrounding layoffs, closures and the services provided to their impacted workforce for tracking and compliance. This includes Union information (if applicable), Corporate information, ability to create notes and ability to upload various documents with a large file size (reference OhioRED); utilized by every program for job placements and providing services to employers.

C

E.3.11 The System must provide a centralized database/Repository for easy reporting. This repository will be accessed by a wide variety of state and local entities.

C

E.3.12 The System must support archiving data for retention, then purge data after 7 years.

C

E.3.13 The System must support the interface to the existing Ohio Rapid Response Mobile App (individual registers while at the RR Event that associates the Event ID also and related Survey Questions).

C




Core Capability



E.3.14 The System must incorporate the Survey Questions by allowing data to come into the new Case Management database and specific screens.

C

E.3.15 The System must connect the RR Employer/Event with each individual in Case Management system to track services and activities through re-employment.

C

E.3.16 The System must connect the RR Employer/Event with Employer Services provided to the employer by location.

C

E.4 Veterans

Veterans' workforce services alleviate unemployment and underemployment for veterans and other eligible persons.

https://www.doleta.gov/oa/veterans.cfm https://www.dol.gov/vets/VPLS/VPLDirectory.html

E.4.1 The System must distinguish DVOP and LVER staff, services, and activities.

C

E.4.2 The System must support generating an Employment Plan with Goals.

C

E.4.3 The System must support a separate Veterans Assessment. CE.4.4 The System must have the ability to add goals to the

Employment Plan.C

E.4.5 The System must have the ability to add a new participating service titled: "received individual career services"(all veterans assigned to JVSG individual career services, must have this service to maintain DOL Performance ICS rate) due to the removal of intensive services.

C

E.4.6 The System must have the ability to select "Significant Barriers to Employment" (more than 1).

C




Core Capability



E.4.7 The System must support VR&E Chapter 31: Labor Market information referral and not enter into Case Management, but able to give a Non-Participating “Provided Labor Market Information” service. Ability to designate and track active VA Chapter 31 referrals. (Pop up when entering into Case Management asking if Chapter 31 Employment)

C

E.4.8 The System must have the ability to track military branch of service of veteran to include National Guard and reserve components.

C

E.4.9 The System must have the ability to designate and track Military Occupations with available crosswalks to O Net Codes.

C

E.4.10 The System must have the ability to designate and track Military Spouses of Active Duty military (Non-JVSG).

C

E.4.11 The System must have the ability to designate and track HVRP veterans.

C

E.4.12 The System must have the ability to designate and track eligible persons.

C

E.4.13 The System must make Vet forms available online. CE.4.14 The System must have online Job Ready Worksheet that is

editable until the case exists (Ohio will provide the template).

C

E.4.15 The System must be able to Terminate a veteran anytime. CE.4.16 The System must have VA Chapter 31 Indicator on the

Employment Plan and Caseload view.C




Core Capability



E.5 RESEA and UCRS

Recipients prioritize RESEA services to transitioning, honorably discharged veterans and individuals likely to exhaust their UI benefits.

Programs connect participants with in-person assessments and re-employment services through their local their local American Job Centers including developing an individual re-employment plan; providing relevant and timely labor market information, identifying job skills and employment prospects; and reviewing claimant’s continued eligibility for UI benefits.

https://www.doleta.gov/Programs/Wagner_Peyser.cfm

E.5.1 The System must have the ability to calculate a worker profiling score from the data received from the UI Operations system of record. The functionality for the scoring must have the ability to be updated yearly.

C

E.5.2 The System must have the ability for staff to sort and select individuals by county for RESEA or UCRS services.

C

E.5.3 The System must have the ability to receive and track multiple dates/rescheduled RESEAs by individual/claim id (self-scheduler).

C

E.5.4 The System must provide a feed (frequency to be determined) from the UI Operations System of Record that includes claim id, date of initial UI claim/allowed date and data required for profiling model, and UCRS and RESEA status/indicator.

C

E.5.5 The System must support a feed to OMJ that includes the UCRS and RESEA status/indicator.

C

E.5.6 The System must support a feed to Ohio UI System that includes UC claim id, UCRS and RESEA status/indicator.

C




Core Capability



E.5.7 The System must have a feed from OMJ to the system of record that includes RESEA completed activities and the date of the one-on-one session from the self-scheduler tool.

C

E.5.8 The System must have a feed (frequency to be determined) to UI Operations System of Record that includes the RESEA status; for example, failed to report, refused service, rescheduled, rescheduled date, completed and completed date.

C

E.5.9 The System must have the ability to identify and report potential issues, negative outcomes, which may be the basis for disqualification from UI benefits. Often referred to as ‘negative reporting’. These situations include, but are not limited to, failure to apply for job referrals, failure to accept work offered and failure to report to job interviews and other reemployment activities.

C

E.5.10 The System must have separate work queues service delivery staff and supervisory/administrative staff.

C

E.5.11 The System must serve as the single repository/source for program reporting purposes.

C

E.5.12 The System must provide a feed to the State of Ohio print shop to generate and mail correspondence to individuals.

C

E.5.13 The System must have the ability to conduct work through the various systems and databases used to run the program.

C

E.5.14 The System must have the ability to view program progress in the form of a dashboard-visual representation by county of program results.

C




Core Capability



E.6 Wagner Peyser (Labor Exchange)Wagner-Peyser provides labor exchange services, such as job search assistance, job referral, and placement assistance for job seekers, and recruitment services for employers with job openings.

Federal regulations reference:https://www.doleta.gov/Programs/Wagner_Peyser.cfm https://wdr.doleta.gov/directives/https://www.doleta.gov/programs/laws_regulations.cfmhttps://www.doleta.gov/reports/dpld_legislative.cfmhttps://www.doleta.gov/reports/dpld_regulatory.cfm

E.6.1 Must have the ability to register and track the universal customer coming into the Ohio Means Jobs Centers for all 88 counties. To include self-directed services, basic demographics, skills, employment history, and the ability to pull reports with this data.

C

E.6.2 The system must be capable of tracking the universal customer from registration through follow up.

C

E.6.3 The Employment Plan must have the functionality to capture Self- directed Services (via interfaces) to include Staff Assisted Career services.

C

E.7 Re-Entry (REO)

https://www.doleta.gov/REO/eta_default.cfm

E.7.1 The System must have self-service and manual functionality in separate application (outside case management system).

C

E.7.2 The System must have current jobs data available for individual to find by county (doesn’t contain contact data).

C

E.7.3 The System must be accessible from correctional institutions (One Stops to provide and assist prior to release).

C




Core Capability



E.7.4 The ability to specifically identify and track incarcerated individuals more clearly.

C

E.8 Migrant Seasonal Farm Workers

Migrant and Seasonal Farm Worker services has information for those working or interested in agricultural jobs.

Employers may find the talent needed each season through our outreach representatives in our centers.

https://www.doleta.gov/MSFW/ https://www.doleta.gov/Farmworker/ https://www.doleta.gov/Farmworker/html/regulations.cfm E.8.1 The System must be capable of allowing Monitor Advocate

track and follow the details of each Migrants activities. C

E.8.2 The System must have a separate MSFW Assessment. CE.8.3 The System must have online application/mobile app (allow

MSFW staff to register migrants at their placement location). This will allow the data to come back in to the system and create a new case.

C

E.8.4 The system must have Employment Plan functionality to include every placement for each individual migrant throughout the entire season. This will include each employer name, address, type of crop, crop duties, start and end dates of placement.

C




Core Capability



E.9 Foreign Labor Certification FLC

Foreign Labor Certification (FLC) program is the first stage of employment-based immigration to hire foreign workers when there are an insufficient number of domestic workers willing, able or available to fill job openings.

https://www.foreignlaborcert.doleta.gov/about.cfm https://www.foreignlaborcert.doleta.gov/reg.cfm

E.9.1 The System must have the ability to interface with OMJ to receive the completed online employer forms to include the VISA number approved by DOL (Permanent, H-1B, H-2A, H-2B, D-1) back to the case management system; this will complete basic steps to obtain labor certification.

C

E.9.2 The System must have the ability to store all forms, track the FLC related employers, and job postings in the database.

C

E.9.3 The System must have a reporting database in the case management system to ensure tracking and monitoring.

C

E.9.4 The System must have the ability to create reports and statistical analysis internally and for employers/agents as well as tracking to include length of time in FLC.

C

E.9.5 The System must have the ability to edit, change pages of a PDF submission as well as separate or combine documentation submitted.

C

E.9.6 The System must have the ability to view job orders, job posting, qualification information as well as any other information needed.

C




Core Capability



E.9.7 The System must have the ability to send requests for a Housing Inspection to the Department of Health along with the ability to send system generated notices to those employers.

C

E.9.8 The System must support application tracking. CE.9.9 The System must have the ability for representatives of

employers to register and submit application information (H-2A - ETA 790 and 9142-A and H-2B- JFS 01809 and 9142-B) as well as supporting documentation electronically for an employer or multiple requests for an agent.

C

E.9.10 The System must maintain electronic files of all documentation received as well as notifications and determinations (ex. Current FileNet).

C

E.9.11 The System must have the ability to interface with Department of Health in order to receive completed Housing inspection forms and have it come back into the case management system.

C

E.9.12 The System must provide staff the ability to track the status of employers through a dashboard of those employers who have submitted housing inspections forms as well as their seven (7) other required tasks.

C

E.9.13 The System must have the ability to track guest workers who have been referred and hired by either the H2A or H2B employers.

C

E.9.14 The System must have the ability to create an extract for DOL reporting specific to FLC performance measures.

C




Core Capability



E.10 Apprenticeship

Apprenticeships teach high-level skills for today's workplace by combining classroom and on-the-job training.

E.10.1 The System must support Apprenticeships - logging actual customers going through the apprenticeship program from beginning to end.

C

E.10.2 The System must support reporting used to audit businesses- making sure the facility is up to code.

C

E.10.3 The System must support the interface with WIET for registered Apprenticeship employers.

C

Requirement Type definitions: C is a critical component of the system. D is a desirable component of the system.


11 Table F: Trade Program Specific Requirements - Optional



Core Capability



F.1 Trade - Optional

Trade program assists workers who have lost or may lose their jobs as a result of foreign trade, with opportunities to obtain the skills, credentials, resources, and support to become reemployed.

Trade is program that provides a variety of re-employment services and income support to assist individuals who have become either unemployed or had hours reduced as a result of increased imports from or shifts in production to foreign countries.

Mandated by Federal Law: https://www.doleta.gov/tradeact- TRADE 20 CFR, Part 618; 20 CFR, Part 617; 29 CFR, Part 90; TEGL 5/15

F.1.1 The System must support a feed (frequency to be determined) to the Ohio UI System that includes: petition information, worker list, Benefit Rights Information (BRI) status, training contract information - TAA law chosen, length of training, dates of training, scheduled breaks, waiver status, dates of waiver, benchmark status/fail, and the changes included in each amended version of the documents.

C

F.1.2 The System must provide a feed to OMJ that includes individual worker information and BRI status.

C

F.1.3 The System must support a feed (frequency to be determined) from the Ohio UI System that includes attendance verification information, overpayment/fraud determination status, and whether the individual is in receipt of TRA or other unemployment-issued cash benefit.

C




Core Capability



F.1.4 The System must support a daily feed to OAKS or CFIS that includes information to make payment to providers, employers or other entities.

C

F.1.5 The System must support a feed (frequency to be determined) with the Ohio UI System that includes information regarding appealed determinations.

C

F.1.6 The System must provide a feed to the Office of the Attorney General that includes information concerning certified debt for collection.

C

F.1.7 The System must provide a daily feed to the Treasurer of State that includes warrant information required to pay benefits to individuals.

C

F.1.8 The System must build and support database tables for TAA petitions, waivers, and TAA contract data. The System must be able to support other federal programs or benefits, including but not limited to, and TAA benefits including Alternative Trade Adjustment Assistance (ATAA), and Re-employment Trade Adjustment Assistance (RTAA).

C

F.1.9 Separate work queues for the petitions, service delivery, and contract staff.

C

F.1.10 The System must support a feed (frequency to be determined) to the Ohio UI System that includes: petition information, worker list, Benefit Rights Information (BRI) status, training contract information - TAA law chosen, length of training, dates of training, scheduled breaks, training costs, waiver status, dates of waiver, benchmark status/fail, and the changes included in each amended version of the documents.

C

F.1.11 The System must support a feed to OMJ that includes individual worker information and BRI status.

C




Core Capability



F.1.12 The System must support a feed (frequency to be determined) from the Ohio UI System that includes attendance verification information, overpayment/fraud determination status, and whether the individual is in receipt of TRA or other unemployment-issued cash benefit.

C

F.1.13 The System must support a daily feed to OAKS or CFIS that includes information to make payment to providers, employers or other entities.

C

F.1.14 The System must support a feed (frequency to be determined) with Ohio UI System that includes information regarding appealed determinations.

C

F.1.15 The System must support a feed to the Office of the Attorney General that includes information concerning certified debt for collection.

C

F.1.16 The System must support a daily feed to the Treasurer of State that includes warrant information required to pay benefits to individuals.

C

F.1.17 The System must build database tables for TAA petitions, waivers, and TAA contract data.

C

F.1.18 The System must have the ability to upload certified worker data in multiple formats (.xls, .csv, etc.) into the case management system (system of record).

C

F.1.19 The System must have the ability to add individual worker data to the case management system.

C

F.1.20 The System must have separate work queues for the petitions, service delivery, and contract staff.

C

F.1.21 The System must support a determination and appeal structure for training contracts, job search allowances, relocation allowances, and other TAA benefits.

C

F.1.22 The System must support ODJFS staff in handling 30-day follow-up requirements.

C

F.1.23 The System must support ODJFS staff in managing waivers. COhio OWST Project RFP State of Ohio p 74



Core Capability



F.1.24 The System must maintain WIOA integration information and ability to refer to WIOA and Wagner-Peyser.

C

F.1.25 The System must have queue to assign new customers - multiple at a time.

C

F.1.26 The System must assign cases automatically transfer to identified caseload to specific Case manager.

C

F.1.27 The System must provide an alert to case manager of new cases.

C

F.1.28 The System must have the ability for case manager to view caseload and sort by multiple data fields.

C

F.1.29 The System must have the ability for supervisor to view caseloads of all team members and individual case manager and sort by multiple data ranges.

C

F.1.30 The System must have the ability to transfer cases between case managers.

C

F.1.31 The System must identify of petition information. CF.1.32 The System must identifier for what benefits customer is

utilizing.C

F.1.33 The System must have the ability to run reports on customers participating in trade benefits by specific benefits and those who obtained employment by petition number and specific areas.

C

F.1.34 The System must have the ability to upload documents. CF.1.35 The System must send out automatic TDP letters for newly

assigned customer. C

F.1.36 The System must support ability to complete transportation worksheet.

C

F.1.37 The System must have the ability to enter waivers, benchmarks and progress reports to feed into benefit system.

C

F.1.38 The System must have the ability to submit training/OJT contracts and modifications.

C




Core Capability



F.1.39 The System must have the ability to submit relocation and job search application.

C

F.1.40 The System must have the ability to send out manual benchmarks.

C

F.1.41 The System must have the ability to keep track of training contracts and modifications.

C

F.1.42 The System must have assessment to feed into employment and/or training plan.

C

F.1.43 The System must have the ability for a case manager to email customer updates, requests, or documents.

C

F.1.44 The System must have a conversational notepad for case manager and supervisor to communicate back and forth.

C

F.1.45 The System must have the ability for supervisor to mark areas of concern.

C

F.1.46 The System must have the ability to access Employer Resource Information Center (ERIC) in order to obtain information on employers who are closing, the number of workers they have on payroll, etc.

C

12 Table G: WOTC Program Specific Requirements - OptionalRequirements Type definitions: C is a critical component of the system. D is a desirable component of the system.


Program Services RequirementsThe following section depicts program specific requirements and provides program specific capabilities which supplements the above Table B: OWST Business Requirements


Core Capability



G.1 WOTC - Optional

Work Opportunity Tax Credits (WOTC) are tax incentives for businesses hiring individuals from certain groups of disadvantaged job seekers who face significant barriers to employment.

https://www.doleta.gov/business/incentives/opptax/https://www.doleta.gov/business/incentives/opptax/docs/WOTC_Fact_Sheet.pdf G.1.1 The System must have the capability to identify seekers that

hits a specific target group for WOTC.C

G.1.2 The System must have a WOTC dashboard that will help the WOTC team to manage those qualified individuals that match a specific target group that will track the individual to the employer.

C

G.1.3 The system must have the ability to be yearly modify with the selected WOTC target groups based on DOL policy.

C

G.1.4 The System must provide an interface with Ohio Dept. of Corrections (ODRC) - weekly contains released individuals.

C

G.1.5 The System must accept WOTC uploaded federal documents from Employers OR create an online application or mobile app for employers to list individuals they Hired with details. This data will be sent to the case management system/database.

C

G.1.6 The System must have functionality that will verify the employer hire date/28-day rule. The System must also have the capability to connect Employer who received incentives with Employer Services (system generated or manually entered).

C


Program Services RequirementsThe following section depicts program specific requirements and provides program specific capabilities which supplements the above Table B: OWST Business Requirements


Core Capability



G.1.7 The System must upload completed forms from Employer on individuals for which incentives were given individually or in bulk.

C

G.1.8 The Protecting Americans from Tax Hikes Act of 2015 (the PATH Act) retroactively reauthorizes WOTC for a five-year period, from January 1, 2015 to December 31, 2019. The System must be capable of processing applications from 1/1/15.

C

G.1.9 The System must generate/view electronic notices to employers/agents; internal view of notices.

C

G.1.10 The System must be able to deny an application that is considered a re-hire or duplicate and generate a notice.

C

G.1.11 The System must be able to deny an application when the target group is no longer valid and generate a notice.

C

G.1.12 The System must be able to retain multiple deficiency reasons.

C

G.1.13 The System must be able to retain multiple denial reasons. CG.1.14 The System must have the ability for other state agencies to

submit requests for benefits from Ohio to include SNAP, TANF, UI benefits and UI wages.

C

G.1.15 The System must have the ability for employers/agents to add, update, and view power of attorney authorizations - provide approval by WOTC team.

C

G.1.16 The System processing of a certification for an application submitted by an agent must only be done when a valid Power of Attorney is on file.

C

G.1.17 The System must create reports and statistical analysis internally and for employers/agents as well as tracking to include length of time in WOTC and FLC.

C

G.1.18 The System must be able to view job order, job poster, qualification information as well as any other information needed.

C


13 Table H: CFIS Program Specific Requirements - OptionalRequirements Type definitions: C is a critical component of the system. D is a desirable component of the system.



Core Capability



H County Finance Information System – OptionalH.1.1 CFIS is used as the State of Ohio’s financial reporting

system to establish budgets, allocate federal and state funding, and process payments to counties through a vouchering system which ultimately provides central reporting to the entire state.

CFIS is currently a web-based application which contains multiple integrated modules. These modules include but are not limited to CFIS Main, Ledger Reporting, CFIS Client Tracking, CCMEP which interfaces with OAKS, and other Ledger Reporting financials. These modules provide a hierarchical structure that ensures data integrity from the distribution of Federal and State allocations to expenditure reporting.

D


Each county within the state of Ohio uses CFIS to request funds by program and by funding source. All 88 counties use CFIS to perform draws, tracks allocated amounts, county mandates shared, audit exceptions, and monthly actual expenditures.

ODJFS is not looking to replace CFIS but rather a provider that can interface with the main CFIS Hub as well as potentially take over or enhance three of the modules that OWD currently uses: CFIS Client Tracking, CCMEP, and Ledger Reporting.

The CFIS and fiscal system interface requirements in the preceding tables and in supplement 4 represent the current interface and functional split between the OWCMS system and the State of Ohio CFIS system. If the offeror has an integrated fiscal management function or has firm plans for such a system, the offeror must use this section to report what is available and how it is integrated.


H.1.2 CFIS Data Interfaces Requirements

1. Real time feed between the case management system of record and the Main CFIS Hub to include registered clients in the OMJ Center and services provided during the eligibility and enrollment process.2. Nightly batch updates from the system of record to the State Fiscal system to include approved ITA vouchers, new clients received through other sources (OMJ, CRISE, OB), and basic OMJ services provided to include services pending funding approval.3. Nightly batch of any new clients registered through the OMJ Center in the CFIS OMJ Module as well as the CFIS Client Tracking module to the case management system of record.4. The ability to maintain the Key Master Data to include services, projects, and funding sources.5. See Interface Section for list of other interfaces.

C

H.1.3 OhioMeansJobs (OMJ) Center Needs- Client Level Tracking Module

A Self-Service Resource Room application to allow the local areas to track the resource room attendance.

If the functionality is not available or the State decides not to take the option, the Contractor must have the ability to turn off the functionality and interface with the current CFIS application. The State also requires essential data fields to display in the case management system of record.

1. A built base structure that maintains the OMJ Centers by state and local areas to include policies and client registration fields.

2. The ability to manage local level services, assign services to cases, and to link them to state services from each area.

3. The ability to allow each local area to manage their own

D


unique required client registration fields. 4. The ability to manage client visits to the OMJ Center or

basic career services completed by the OMJ staff without duplication for the entire state; the ability to activate and inactivate clients if no activity for 6 months.

5. The ability to maintain provider information related to the Memorandum of Understanding (MOU) agreements by local areas.

6. Resource Center Workstation management section including workstation protection, and automatic logoff based on idle timer for ease of management for the OMJ Administrators.

7. Convert any laptop/desktop with internet access into a kiosk station, mainly for Virtual OMJ Centers.

8. Ensuring the appropriate OMJ Centers get credit based on the center visited by the client, irrespective of where the client initially registered.

9. Client Check-in/Check-out Management, including manual check-out, automated check-out at night, add additional services to the visit log.

10. Complete functionality to schedule, track and report workshops, including pre-registration.

11. Manage Referrals To/From Partners, including automated e-mail notification to partners and recording service accurately related to the appropriate entity.

12. Transfer One-Stop Services (Foot-Traffic) Data to and from WCMS, including real-time as well as nightly batch process to report clients and visits accurately.

13. Must have the ability to create ad hoc detailed spending reports by WIB, State, and provider levels.


H.1.4 Resource Room Configuration Needs

1. Easy install, setup, and configuration for the local OMJ Administrators.

2. Complete flexibility for local OMJ Administrators to set up workstations in their own way i.e.- desktop control, changes to resource room workstations to kiosk machines and vice-versa on the fly as demanded.

3. Flexibility for the local areas to track web-sites and/or programs used by the clients in real time.

4. Export capabilities from the system of record to Excel for case load and performance reporting.

5. Convert any laptop/desktop with internet access into a kiosk station, mainly for Virtual OMJ Centers.

D

H.1.5 Fiscal Application Individual Training Account (ITA) Needs:

If the functionality is not available or the State decides not to take the option, the Contractor must have the ability to turn off the functionality and interface with the current Fiscal application. The State also requires essential data fields to display in the case management system of record.

1. Maintain WIOA approved vendors/Providers and State Approved vendors for ITA's.

2. Must have a two-way communication with CIFS Main and the case management system of record in order to maintain funding and other spending limits for programs based on Federal compliance, the ability to accept WIOA fiscal agent changes such as client funding limits by service type, the ability to move funds from program to program, setting aside spending limits to manage the direct service amount by grant/service.

3. Maintain client details by each local area in real time such as eligibility and allowable services from the system of record. Details include receiving funding and service amounts, obligations, accruals, and expenses per client by month.

4. The ability to have a two-way communication with CFIS

D


Main and the case management system of record on approved and/or denied services in real time, such as any training and/or supportive services.

5. The ability to pull reports from the State fiscal system for multiple levels of tracking by client including funding limits, commitments, obligations, accruals, expenses by client by month for each sub-area, fiscal agent, local and state.

6. The ability to transfer cases from one county to another-i.e. the county that provides services pays for those services.

7.The ability to locally select as many funding sources per service.

8. Functionality to issue and print ITA vouchers. 9. CCMEP and the Office of Food Assistance related edit

rules that will flag TANF cases after four consecutive months of TANF distributed funds.

10. The ability to report cost per client by each local area, fiscal agent, and state levels for direct services.

11. The ability to report average cost per client even for indirect or pooled services by each local area, fiscal agent, and state level.

H.1.6 CCMEP and Program Staff Functions: CCMEP Module.

This module is the CCMEP structure which includes other related programs such as, WIOA Youth and TANF, to manage the assigned activities/assignments to the County and to maintain the Lead Agencies.

If this functionality is not available or the State decides not to take the option, the Contractor must have the ability to turn off the functionality and interface with CFIS application. The State also requires essential data fields to display in the case management system of record.

1. Once services (training, supportive services) are approved in the case management system of record need to have a

D


real-time eligibility and allowable service interface with CFIS Main using web services technology.

2. Maintain funds and service amounts including commitments, obligations, accruals and expenses by Client and month.

3. Functionality to review and approve case plan and services. Batch Service approval process prioritizing veterans.

4. Allow Fiscal staff to move funds between projects within Allowable Services.

5. Multiple Levels of Tracking by Client including Lifetime limits, Commitments, obligations, accruals, expenses by client by month.

6. Report all CCMEP related cost per client at Sub-Area, Fiscal Agent and State levels for direct services.

7. Report all average cost per client even for indirect or pooled services at Sub-Area level.

8. The ability to provide and track services for all CCMEP programs (both WIOA & TANF) at the client level.

9. Have the flexibility to accommodate different business processes at each of the local areas and sub areas.

10. Have the ability to identify both WIOA Youth and TANF funds for program case management during client tracking.

11. Flexibility to identify other grants and intelligently separate, cost allocate, and consolidate to the appropriate subset.


H.1.7 Reports

1. Must have the ability to create ad hoc reporting by WIB, State, and provider level.

2. Must have the ability to customize each report based on all the data fields, performance year/quarter, and date range (all data elements must be in the reporting database).

3. Must have the ability to download reports either into our current Cognos reporting structure, if no other reporting system is available or if JFS decides not to take the reporting option.

D

14 Table I: Labor Management Information Program Specific Requirements - OptionalRequirements Type definitions: C is a critical component of the system. D is a desirable component of the system.



Core Capability



I Labor Market Information - Optional

Labor Market Information (LMI) compiles reports and data about employment and unemployment, wages and earnings, job outlook, training resources and careers. Make good business decisions, develop job descriptions, and learn about wages.

I.1.1 The System may provide a Labor Market Information (LMI) component that provides analysis capabilities of individual and employer demographics, industries and occupations, work force, wage and education information, and economic indicators.

C




Core Capability



I.1.2 The System must provide an electronic interface with the Ohio Bureau of Labor Market Information.

C

15 Table J: Document Imaging Specific Requirements - OptionalRequirements Type definitions: C is a critical component of the system. D is a desirable component of the system.



Core Capability



J Document Imaging Features - Optional

Labor Market Information (LMI) compiles reports and data about employment and unemployment, wages and earnings, job outlook, training resources and careers. Make good business decisions, develop job descriptions, and learn about wages.

J.1.1 The System must provide for the ability of an authorized user to upload documents to a Case that can be sued for various programs.

C

J.1.2 The System must allow an authorized user to view/print/save documents from the System. User access to view/print/save documents will be the same as Case access rights.

C




Core Capability



J.1.3 The System must provide the ability to upload documents and images in formats that are universally acceptable (pdf, tiff, jpg, .doc, .xls, etc.). Videos and pictures are common in the Case file. An archival standard may be necessary to support document retrieval long term.

C

J.1.4 The System must allow authorized users to upload multiple documents at once. Multiple documents may be associated to one Intake or Case.

C

J.1.5 The System must provide the ability to enter comments associated to a document.

C

J.1.6 The System must provide the ability to associate a category to an uploaded document from a pre-defined list (Intake, Investigation, Person, Legal, Referral, Case Plan, etc.). A common pre-defined list will be provided by the business team during the detailed requirements phase. Implementation may be upload within each section or a common upload page to be determined in the design phase.

C

J.1.7 The System must provide a visual cue while the system processes the document upload.

C

J.1.8 The System must provide a warning message when the user attempts to upload a document that is too large or in the wrong format.

C

J.1.9 The System must provide a confirmation when the document upload is successful.

C

J.1.10 The System must allow an ODJFS Administrator to delete a document from an approved Case. Delete must be a 'soft' delete and maintain the document associations. Access to the deleted document, including comments, may be necessary for court actions.

C

J.1.11 The System must provide the ability to cancel a document upload prior to the Save action.

C




Core Capability



J.1.12 The System must provide a centralized location to search and manage documents.

C

16 Table K: Job Seeker Interface Specific Requirements - OptionalRequirements Type definitions: C is a critical component of the system. D is a desirable component of the system.




Core Capability



K Job Seeker Interface Features - Optional

ODJFS has recently made a tablet application available for the participants in Rapid Response events. This application is built using Kony platform to allow the participants to go paperless entering their information directly into the system. It is a native application that is available on both on iOS and android devices. This application scans their driver’s license, can capture document images using the camera on the device and supports the interaction for supplementary data to ensure complete applications.

In this section, we are looking to build on the application that exists to take several more programs paperless.

K.1 WIOA Tablet InterfaceThis section deals with the mandatory forms and user data collection for this program.

K.1.1 The System must provide a tablet interface that build on the current ODJFS Rapid Response software base to take each of the 3 forms paperless. This application must be available to both iOS and Android devices.

C

K.1.2 The System tablet application must use the driver’s license scan to gather data that is available through that mechanism. In addition, the app must allow for the possibility that no driver’s license is available at the time.

C

K.1.3 The System tablet application must have the capability to capture images of documents and upload them to the case file. The System must provide the ability to enter comments associated to a document.

C




Core Capability



K.1.4 The System must accept images from the application of upload documents and images in formats that are universally acceptable (pdf, tiff, jpg, .doc, .xls, etc.). Videos and pictures are common in the Case file. An archival standard may be necessary to support document retrieval long term.

C

K.1.5 The System tablet application must have the capability of capturing and storing signature.

C

K.1.6 The System must provide the ability to recreate an image of the form from the data collected including signatures where applicable.

C

K.2 Trade Tablet Interface

This section deals with the mandatory forms and user data collection for this program.

K.2.1 The System must provide a tablet interface that build on the current ODJFS Rapid Response software base to take each of the 15 forms paperless. This application must be available to both iOS and Android devices.

C

K.2.2 The System tablet application must use the driver’s license scan to gather data that is available through that mechanism. In addition, the app must allow for the possibility that no driver’s license is available at the time.

C

K.2.3 The System tablet application must have the capability to capture images of documents and upload them to the case file. The System must provide the ability to enter comments associated to a document.

C




Core Capability



K.2.4 The System must accept images from the application of upload documents and images in formats that are universally acceptable (pdf, tiff, jpg, .doc, .xls, etc.). Videos and pictures are common in the Case file. An archival standard may be necessary to support document retrieval long term.

C

K.2.5 The System tablet application must have the capability of capturing and storing signature.

C

K.2.6 The System must provide the ability to recreate an image of the form from the data collected including signatures where applicable.

C


17 Service Level Agreements - Operations

17.1 Parties and Timeline

This Service Level Agreement is between the Contractor and the State of Ohio. This service level agreement is effective as of the date of award of this Contract. ODJFS and the Contractor must review at least quarterly to determine if any modifications or amendments are needed to reflect the Ohio support requirements and Contractor’s services.

17.2 Service Catalogue

The Contractor will provide the following services to the State of Ohio:

Service Description ExamplesUser Support Receive, document, and prioritize

issue tickets and help state, county, and local partner users in the use of existing applications or services.

Provide help desk support Answer queries about applications. Receive and document bug reports. Collect and document requests for

changes. Share status of requests.

Problem Correction

Bring a record back to its original functionality before the problem arose. This may include a permanent fix or a temporary work around until a permanent fix is found.

Fix bugs. Retrieve functionality after abnormal

program terminations. Complete root cause analysis.

17.3 Deductions

A 5% deduction from the Contractor’s monthly invoice for the month in which one or more of the SLA levels were not met.

17.4 Reporting

The following processes will be used in order to manage the application. Agenda, schedules and expected content will be discussed and agreed upon at the kick-off meeting for the project.

17.4.1 Weekly Status Report

The Contractor to provide ODJFS with a weekly status report that gives an overall summary of the following:

Project health; On-going activities;


Completed tasks; Upcoming milestones and releases; Bug reports; Risk identification and mitigation plan; and Action items across.

17.4.2 Monthly Review Meeting

Metrics must be tracked by Contractor, summarized in a dashboard format, and discussed in a monthly meeting. This activity includes the following:

Tracking unresolved issues from maintenance projects which impact the SLA; Updating maintenance project progress and resolving critical issues; and Capturing agreements and disagreements and items needing escalation.

17.4.3 Quarterly Review Meeting

A quarterly review meeting will include the following:

The SLA will be reviewed with the managers involved and an amendment will be created if required; Review process will be through teleconference or face-to-face meeting session which will be booked in advance; Review document prepared by Contractor that will include overall project status, issues list, metrics reporting, supporting reasons for

metrics deviation, and items that need adjustment within SLA (e.g. scope, metrics, etc.); and SLA changes will be tracked by version number and date.

17.4.4 Reporting Service Levels

Type MeasurementWeekly Status Report Delivered at not less than seven calendar day intervals

Monthly Status Report Delivered at monthly intervals and not less than two business days before scheduled review meeting

Quarterly Status Report Delivered at quarterly intervals and not less than five business days before scheduled review meeting

17.5 User Support and Problem Correction

These guidelines will be used to respond to production problems that are received by the Contractor’s Help Desk or directly as an escalation from ODJFS. A production problem is defined as an unplanned production system event which adversely affects application processing or application deliverables.


Measurement period for User Support and Problem Correction SLAs is a calendar month. For example, if an SLA is not met during the month of April, one 5% deduction (as outlined in the SLA associated with that particular service) will be applied to the invoice for the month of April, and if it is not met for the month of May, an additional 5% deduction will be applied to the invoice for the month of May.

17.5.1 Prioritization Approach

Service requests for production problems received by the Contractor’s help desk or ODJFS problem escalation will be given a Severity Code from 1 – 4 based on how important responding to the problem is to the primary business of OWD, as well as the availability of workarounds. The Severity Code will be the basis for scheduling work on the backlog and assigning resources to the request. Critical, urgent, and routine application functions are defined in the section below on Application Function Type.

Severity Code Definition1 Severity Level One – there is a complete or severe loss of service in at least one

business critical area. The impact is that state, county or local partner program business operations cannot reasonably continue or can continue only in a restricted fashion, and services to customers is disrupted. Repetitive problems at Level One may be grounds for Contract termination.

2 Severity Level Two – there is a minor loss of service. The impact is an inconvenience and business critical areas are not significantly impaired. The state, county or local partner program business operations continue with minimal disruption to customers. A workaround acceptable to ODJFS may be employed temporarily to restore service and/or business operations.

3 Severity Level Three – there is a deviation from the Standard of Performance that causes no loss of service. This may be a minor error, incorrect behavior, or a documentation error that does not impede the operation of a system or effect ODJFS business operations. Customers are not impacted.

4 A problem has diminished routine application functionality or performance.

17.5.2 Application Function Type

The table below provides examples of critical, important, and supportive application functions. Further conversation with the Contractor will help to ensure all services are mapped to the correct category.

Application Function Type Description Examples


Critical

These application functions are critical to ensuring business requirements or ODJFS reputation. Extended failure will impact program participants, or employers, or damage ODJFS reputation.

Common IntakeJob MatchingJob ReferralAssessmentsOMJ/Ohio Benefits Interfaces

Urgent

These application functions are important to business productivity but are not critical Workforce Development services nor critical to ODJFS reputation.

Other System InterfacesReportingProvider List

RoutineThese applications support productivity but are not essential to business effectiveness.

17.5.3 Response and Resolution Times

Severity codes are used in order to determine appropriate response and resolution times. Response and resolution times are measured from when the incident is opened by the help desk. If the problem is not resolved within the defined timeframe, continuous effort will be applied until the problem is resolved.

Severity Code

InitialResponse

Estimation Response

Subsequent Responses Resolution

1 15 minutes 2 hours Every 30 min. 8 hours2 30 minutes 2 hours Every 2 hours 2 business days3 1 hour 8 hours Daily 10 calendar days4 1 hour Next business day Weekly 60 calendar days

Initial Response is when a ticket is opened and acknowledged by help desk staff. This ticket will be conveyed back to the originator with proposed severity level noted. Initial severity level will be set by the Contractor; escalation process will be available however.

Estimation Response is when the user that logged the ticket is informed of an estimated resolution time. Subsequent Responses is the frequency with which the user that logged the ticket is updated on the resolution status. Resolution is the point at which the problem is resolved, the application function is returned to a usable and available state and the

originator is notified of the resolution.


17.5.4 Response and Resolution Service Levels

If the system fails to meet any of the following Response and Resolution Service levels in a given calendar month, the response and resolution service will be reported as unacceptable and a 5% deduction will be assessed.

Type Measurement

Problem Resolution Less than 90% of problems are resolved in the prescribed resolution interval.

Response/Estimate Less than 90% of Initial Response, Estimation Response, and Subsequent Response times are met.

Maximum Problem Aging No problem is older than 180 days.

17.5.5 Application Availability

Availability is defined as the ability of an end user to access and execute any of the included application functions from a functioning workstation and live network connection. For an application to be available, all of its supporting systems must be operational. “Unavailable” or “Unavailability” means the users are unable to access the Service or use all the Service’s features and functions effectively and efficiently.

Scheduled downtime will occur between 10 p.m. and 6 a.m. Eastern Time, Monday through Saturday. The Contractor may change the scheduled downtime to other non-business hours upon reasonable notice to and approval by ODJFS. Scheduled downtime will not be considered times when the Services are Unavailable. System Availability will be measured weekly, Sunday through Saturday and reported monthly. Application availability metrics will be measured/reported Monthly beginning go-live and through the first four months. Weekly measurement begins the fifth month after go-live. Excludes scheduled maintenance.

Application Level

Business Hour Availability Off-Hour Availability Scheduled Down-Time

DefinitionMonday-Friday 8 am – 5 pm EST

Monday-Friday 5:01pm-7:59 am EST; Sat. and Sun.

Monday-Friday 10 pm – 6 am EST

Critical 99.5% 99.5% To Be mutually agreed upon

Urgent 99% 98% To Be mutually agreed upon

Routine 98% 98% To Be mutually agreed upon

Any additional outages must be scheduled and approved by ODJFS at least two weeks in advance, unless there is an emergency.


1575.6 Application Availability Service Levels

If the system fails to meet any of the following Availability Service levels in a given calendar month, the availability will be reported as unacceptable and a 5% deduction will be assessed.

Type MeasurementCritical Application

AvailabilityAvailability falls below 99.5% for more than 2 days of the month during regular business hours.

Urgent Application Availability

Availability falls below 99% for more than 2 days of the month during regular business hours.

Routine Application Availability

Availability falls below 98% for more than 2 days of the month during regular business hours.

17.5.7 Application Responsiveness Service Levels

Online response time for this application. Response times are only applicable to the System, within the control of the Contractor, as identified in this Contract.

Online response time is measured as the elapsed time from when a request enters the Ohio Workforce Application gateway until the request has been satisfied and leaves the Ohio Workforce Application gateway. This includes processing times of all components covered under this Amendment which participate in fulfilling the request, including but not limited to Firewalls, Load Balancers, WAN/LAN Telecommunications Lines, Web Servers, and Application and Database Servers. The definition of a transaction is any system action that requires a screen to paint, refresh and/or system update to complete during normal operations. Mutually agreed to exception functions will be excluded from measurement.

The Measurement interval is Monday through Friday 8 am – 5 pm EST. Metrics will be collected monthly beginning with go-live month 1 through 4, Weekly, thereafter; Measurements are to be reported monthly.

If the system fails to meet any of the following Application Responsiveness Service levels in a given calendar month, the availability will be reported as unacceptable and a 5% deduction will be assessed against the total monthly subscription fee.

Type MeasurementApplication

ResponsivenessMore than 5% of transactions complete (via State network) > 4.0 seconds

Application Responsiveness

More than 1% of transactions complete in > 10.0 seconds


ohio workforce system transformation project system ... · web viewthe requirements for the ohio...

Documents