Ohio Workforce System Transformation PROJECT SYSTEM ...



Supplement 1:Ohio Workforce System Transformation (OWST)Scope of WorkTable of Contents TOC \o "1-3" \h \z \u 1.Ohio Workforce System Transformation PROJECT SYSTEM REQUIREMENTS PAGEREF _Toc4486502 \h 5System Project Management Requirements (Table A) PAGEREF _Toc4486503 \h 5Ohio Workforce System Transformation Business Requirements (Table B) PAGEREF _Toc4486504 \h 5Ohio Workforce System Interface Requirements (Table C) PAGEREF _Toc4486505 \h 5Common Functional Requirements (Table D) PAGEREF _Toc4486506 \h 5Program Services Requirements (Table E) PAGEREF _Toc4486507 \h 52.ODJFS Project Operational and Administration Support PAGEREF _Toc4486508 \h 53.Site Transition PAGEREF _Toc4486509 \h 63.1 State-owned Data PAGEREF _Toc4486510 \h 63.2 State Owned Capabilities PAGEREF _Toc4486511 \h 63.3 Site Conversion PAGEREF _Toc4486512 \h 73.4 Constraints PAGEREF _Toc4486513 \h 73.5 Automated Conversion Methods: PAGEREF _Toc4486514 \h 73.6 Manual Conversion Methods: PAGEREF _Toc4486515 \h 83.7 Conversion Prerequisites: PAGEREF _Toc4486516 \h 83.8 Conversion Procedures: PAGEREF _Toc4486517 \h 83.9 Resource Requirements: PAGEREF _Toc4486518 \h 83.9.1 Conversion Responsibilities: PAGEREF _Toc4486519 \h 83.9.2 State Conversion Responsibilities: PAGEREF _Toc4486520 \h 94.Exit Strategy PAGEREF _Toc4486521 \h 95.Proposed Platform Future Enhancements PAGEREF _Toc4486522 \h 105Table A: System Project Management Requirements PAGEREF _Toc4486523 \h 116Table B: Business Requirements PAGEREF _Toc4486524 \h 23B.1 General System Capabilities PAGEREF _Toc4486525 \h 23B.2 Technology Driven Capabilities PAGEREF _Toc4486526 \h 27B.3 Flexibility & Automation Capabilities PAGEREF _Toc4486527 \h 27B.4 Program Management Capabilities PAGEREF _Toc4486528 \h 28B.5 (OMJ) Integration PAGEREF _Toc4486529 \h 31B.6 Comprehensive Assessment and Services PAGEREF _Toc4486530 \h 32B.7 Case Intake and Eligibility PAGEREF _Toc4486531 \h 34B.8 Training Providers PAGEREF _Toc4486532 \h 35B.9 Employer Services PAGEREF _Toc4486533 \h 36B.10 Fiscal Management PAGEREF _Toc4486534 \h 37B.11 Communication, Forms and Notices PAGEREF _Toc4486535 \h 38B.12 Reporting PAGEREF _Toc4486536 \h 39B.13 Usability PAGEREF _Toc4486537 \h 42B.14 System Administration PAGEREF _Toc4486538 \h 43B.15 County Data Integration PAGEREF _Toc4486539 \h 447Table C: Interfaces PAGEREF _Toc4486540 \h 44C.1 Interfaces PAGEREF _Toc4486541 \h 44C.2 Interface Interoperability PAGEREF _Toc4486542 \h 479Table D: Common Requirements PAGEREF _Toc4486550 \h 49D.1 Security and Recovery PAGEREF _Toc4486551 \h 49D.2 Identity Management PAGEREF _Toc4486552 \h 50D.3 System Performance and Capacity PAGEREF _Toc4486553 \h 50D.4Hosting PAGEREF _Toc4486554 \h 51D.5Single Sign-on PAGEREF _Toc4486555 \h 52D.6Work Flow PAGEREF _Toc4486556 \h 52D.7Help Search PAGEREF _Toc4486557 \h 53D.8Security User Interface PAGEREF _Toc4486558 \h 54D.9General PAGEREF _Toc4486559 \h 5510Table E: Program Specific Requirements PAGEREF _Toc4486560 \h 56E.1 WIOA Adult and Dislocated Workers. PAGEREF _Toc4486561 \h 56E.2 WIOA Youth Program (CCMEP) PAGEREF _Toc4486562 \h 58E.3 Rapid Response and?Layoff?Aversion PAGEREF _Toc4486563 \h 60E.4 Veterans PAGEREF _Toc4486564 \h 62E.5 RESEA and UCRS PAGEREF _Toc4486565 \h 64E.6 Wagner Peyser (Labor Exchange) PAGEREF _Toc4486566 \h 66E.7Re-Entry (REO) PAGEREF _Toc4486567 \h 66E.8Migrant Seasonal Farm Workers PAGEREF _Toc4486568 \h 67E.9 Foreign Labor Certification FLC PAGEREF _Toc4486569 \h 68E.10 Apprenticeship PAGEREF _Toc4486570 \h 7011Table F: Trade Program Specific Requirements - Optional PAGEREF _Toc4486571 \h 71F.1 Trade - Optional PAGEREF _Toc4486572 \h 7112Table G: WOTC Program Specific Requirements - Optional PAGEREF _Toc4486573 \h 75G.1 WOTC - Optional PAGEREF _Toc4486574 \h 7613Table H: CFIS Program Specific Requirements - Optional PAGEREF _Toc4486575 \h 78H County Finance Information System – Optional PAGEREF _Toc4486576 \h 7814Table I: Labor Management Information Program Specific Requirements - Optional PAGEREF _Toc4486577 \h 86I Labor Market Information - Optional PAGEREF _Toc4486578 \h 8715Table J: Document Imaging Specific Requirements - Optional PAGEREF _Toc4486579 \h 87J Document Imaging Features - Optional PAGEREF _Toc4486580 \h 8816Table K: Job Seeker Interface Specific Requirements - Optional PAGEREF _Toc4486581 \h 89K Job Seeker Interface Features - Optional PAGEREF _Toc4486582 \h 90K.1 WIOA Tablet Interface PAGEREF _Toc4486583 \h 90K.2 Trade Tablet Interface PAGEREF _Toc4486584 \h 9117Service Level Agreements - Operations PAGEREF _Toc4486585 \h 9317.1Parties and Timeline PAGEREF _Toc4486586 \h 9317.2 Service Catalogue PAGEREF _Toc4486587 \h 9317.3Deductions PAGEREF _Toc4486588 \h 9317.4Reporting PAGEREF _Toc4486589 \h 9317.4.1Weekly Status Report PAGEREF _Toc4486590 \h 9317.4.2Monthly Review Meeting PAGEREF _Toc4486591 \h 9417.4.3Quarterly Review Meeting PAGEREF _Toc4486592 \h 9417.4.4Reporting Service Levels PAGEREF _Toc4486593 \h 9417.5User Support and Problem Correction PAGEREF _Toc4486594 \h 9417.5.1Prioritization Approach PAGEREF _Toc4486595 \h 9517.5.2Application Function Type PAGEREF _Toc4486596 \h 9517.5.3Response and Resolution Times PAGEREF _Toc4486597 \h 9617.5.4Response and Resolution Service Levels PAGEREF _Toc4486598 \h 9717.5.5Application Availability PAGEREF _Toc4486599 \h 971575.6Application Availability Service Levels PAGEREF _Toc4486600 \h 9817.5.7Application Responsiveness Service Levels PAGEREF _Toc4486601 \h 98Supplement OneOhio Workforce System Transformation - OWST RequirementsThe 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. 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 mon 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. ODJFS Project Operational and Administration SupportProvide 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.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 DataThe 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; andCoordinate 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 CapabilitiesThe 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 ConversionThe 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; andCapture any additional data required for the initial operation of the new OWST solution.3.4 ConstraintsAll 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; andAll 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; andSpecial 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; andThe 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; andAll 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; andPlaying 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; andPlaying 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.Exit StrategyWithin 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; orUpon notice of termination/partial termination; orUpon 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; andA 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.Proposed Platform Future EnhancementsThe 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.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 RequirementsRequirementTypeOfferor ResponseA.1The Contractor must manage the relationship among its staff and its subcontractors.CA.2The 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.CA.3The 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.CA.4The 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.CA.5The 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).CA.6?The Contractor must provide, as part of the Contract resulting from this RFP, the following Deliverables: Project Plan: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; andOrganizational Change Management Plan.CA.7The 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; andTest planning and tracking.CA.8The proposed Project Plan must include tasks, a schedule and resources from System project initiation to System project implementation in sufficient detail to allow project monitoring.CA.9The proposed Project Plan must be updated and kept current, at least at two-week intervals, throughout System customization, configuration and implementation.CA.10Offeror 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 work products; andContract content review.CA.11Offeror 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);?andRoles, responsibilities, and team expectations.Upon completion of the presentation, the State will immediately assess the health of the project and determine next steps for moving forward with the Project, within one week of the meeting, which may include the following:Continue the Project;Terminate the Contract; 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.? CA.12Offeror 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.CA.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 and System Testing; andHow 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.CA.14The Contractor must be responsible for conducting, documenting, and communicating Unit, Data Conversion, Functional, Integration, Security and System Testing.CA.15The 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.CA.16The 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.CA.17The Contractor must document testing activity including scripts, modules tested, deficiencies detected, and remedies implemented for System and for System Interfaces.CA.18The Contractor must support testing with appropriate data and system configuration changes to support testing of all daily and periodic activities.CA.19The Contractor must conduct knowledge transfer to ODJFS’s technology staff including, but not limited to:Content Management;System design and schema;System usage;System testing techniques (manual and automated);System procedures;Application and tools development;Report generation; Data and Database Administration;Utilities;Application Diagnostic Tools; andSystem administration and maintenance.CA.20The 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; andData Maps for Extracts.CA.21The Contractor must make System documentation available in written manuals in electronic form, and accessible online as part of a help facility for the System.CA.22The Contractor must have an internal quality management function that will use: Internal Quality Assurance (QA) checklists and Quality Audits; andInternal 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.CA.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; andHow Risk Mitigation and Contingency Plans will be developed and implemented.CA.24Offeror 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; andHow it will manage implementation with no disruption to the business or Systems in use by ODJFS.CA.25Contractor must be responsible for a training plan and knowledge transfer to users on the functionality of the System. Classroom training is preferable.CA.26The 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. CA.27Compatible browsers information must display on each page of the site including “white-labeled” or third-party tools.CA.28Must 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.CA.29ODJFS 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.CA.30?Provide a logical network diagram that describes how the infrastructure components will meet the functional requirements.CA.31?Provide conceptual and logical data-flow diagrams. CA.32?Provide a high-level architecture diagram, including logical and physical components. CA.33System documentation must describe error logging and how to access the error logs. CA.34System documentation must describe any batch processing requirements for the application.CA.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; andClustering of servers. CA.36System documentation must clearly describe all versions of the package that are deployed for different scaling situations. CA.37System documentation must clearly describe all activities that affect optimum performance such as service recycling, rebooting, or batch jobs and their frequency. CA.38?Provide conceptual and logical application data-flow models.CA.39Conversion: Must describe their strategy and approach for data conversion, including descriptions of prior similar projects.CA.40Must 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.CA.41Must describe how the system security supports role- based security and protects access to sensitive data.CA.42?Must provide a recovery plan for restoring services in the event of a disaster including system and data restoration.CA.43Offeror must describe the encryption used to protect sensitive data, both in transit between users and the provider, and while data is stored at rest.CA.44Offeror must agree that all ODJFS data that it hosts will be hosted only in data centers located inside the United States.CA.45Offeror 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.CA.46Offeror 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.CA.47Offeror 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.CA.48?The proposed solution must have a completed Project Security Plan and Assessment before Go Live.CA.49The proposed solution must have built-in security controls and meet or exceed current State security requirements as described in Supplement 2. C A.50The proposed solution must complete implementation and provide a production system within 24 months of contract award. CTable 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 RequirementsTypeOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentB.1 General System CapabilitiesB.1.1The System must provide Veterans Priority of Service for all programs administered through the system.CB.1.2The System must provide access to the tables that will allow ODJFS to make system changes when necessary.CB.1.3The System must have the ability to easily transfer cases from one staff to another staff (all programs).CB.1.4The System must have spell check for notes/comment section (system wide for all programs).CB.1.5The 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.CB.1.6The 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.CB.1.7The System must have functionality for electronic signature and the ability to print for all program assessments.CB.1.8The System must provide the ability to view program progress in the form of a dashboard-visual representation by county of program results. CB.1.9The System must provide the ability to upload data to the case management system from Ohio's various 88 counties unique system.CB.1.10The System must have the ability to accept basic intake and basic demographic data via internal and/or external data sharing uploads. CB.1.11The System must have roles supporting an organizational Hierarchy. CB.1.12The System must restrict access to special grant programs to only those users granted the correct user role.CB.1.13The System must provide functionality for Case Management with Individual Plan and tracking of services. CB.1.14The 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.CB.1.15The 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. CB.1.16The System must archive data for retention, then purge data after 7 years. CB.1.17The System must have a Centralized database/Repository for easy reporting.CB.1.18The System must have data export capabilities to Excel for case load and performance reporting.CB.1.19The System must support program integration and service delivery must be in alignment with Title I and Title 3 programs.CB.1.20The System must have the ability to dual enroll customers in multiple programs with the ability to view all programs. CB.1.21The System must have the ability to upload certified worker data in multiple formats (.xls, .csv, etc.) into the case management system (system of record).CB.1.22The System must have the ability to add individual worker data to the case management system.CB.1.23The System must have the ability to export data/reports to Excel and in PDF format for analysis and distribution. CB.1.24The System must have separate work queues for the petitions, service delivery, and contract staff.CB.1.25The System must have a determination and appeal structure for training contracts, job search allowances, relocation allowances, and other TAA benefits.CB.1.26The System must have the functionality for Case Managers with Individual Opportunity Plan and tracking of services.CB.1.27The System must serve as the single repository/source for program reporting purposes.CB.1.28The System must provide a feed to the State of Ohio print shop to generate and mail correspondence to individuals and/or training providers/employers. CB.1.29The System must have the ability to identify customers with multiple (back to back) petitions. CB.1.30The System must provide internal referrals/alerts from program to program.CB.1.31The System must have an intuitive calendar for scheduling appointments.CB.1.32The System must be intuitive so that it can provide step by step screens for every program to assist in reducing errors and inconsistencies.CB.1.33The System must have the ability to send automated emails. CB.1.34The System must have the ability to generate mass emails/texts to individuals seamlessly.CB.1.35The 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).CB.1.36The System must have the ability to link the customers information/events with Outlook.CB.1.37The 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. CB.1.38The 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.).CB.1.39The 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.CB.1.40The 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.CB.1.41The System must provide a web-based user interface that supports state, county, and local partner users.CB.1.42The System must meet W3C web accessibility guidelines and comply with Americans with Disabilities Act standards including section 508.CB.1.43The System must be compatible with assistive technology products, including screen readers, screen enlargement viewers, and text to speech products.CB.1.44For 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. CB.1.45The System must have the ability to have various user roles and privileges with hierarchy, including the ability to mark cases confidential.CB.1.46The 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.CB.2 Technology Driven CapabilitiesB.2.1The System must have dashboards to help manage outcome and performance measures.CB.2.2The System must provide caseload view for staff and supervisors.CB.2.3The System must set specific program business rules to include program checks and balances to reduce errors.CB.2.4The System must provide prompts to notify alerts and triggers.CB.2.5The System must have the ability to track workload and staff performance based on staff ID/program.CB.2.6The System must support a common intake data feed from OMJ with logic to filter down to eligibility across programs.CB.3 Flexibility & Automation CapabilitiesB.3.1The System must support automated forms available for electronic customer signature.CB.3.2The System must support documentation imaging with the ability to upload documents that can be used for various programs.CB.3.3The System must have the ability to automate and prepopulate fields to avoid double entry.CB.3.4The System must have the ability for the State to enter their own unique questions and data fields (i.e.-assessment, eligibility). CB.3.5The System must have the ability for staff to modify sections (by roles - Admin, Supv, Staff); different capabilities.CB.4 Program Management CapabilitiesB.4.1The 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.CB.4.2The System must support program integration and alignment between WIOA and Title I programs wherever possible.CB.4.3The 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.CB.4.4The System must have the ability to add, modify, inactivate and delete other primary programs.CB.4.5The System must provide other primary programs access to all available System capabilities, functions and controls.CB.4.6The 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).CB.4.7The System intake process for other primary programs must be able to utilize the same intake process for federal primary programs. CB.4.8The 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.CB.4.9The 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.CB.4.10Sub programs must have access to the same integrated System capabilities, functions and controls as the primary program.CB.4.11The 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.CB.4.12The System must perform all aspects of program administration (e.g. implementation, performance) for State funded programs as prescribed at the State Level.CB.4.13The 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: System must have the ability to add, modify and delete State programs.CB.4.15The 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.CB.4.16The System must be able to implement Local funded programs as prescribed at the Local Area, County and/or at the Local Partner Level.DB.4.17The 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.DB.5 (OMJ) IntegrationEmployers 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.1The System must have a bi-directional interface with , Ohio’s mandated system (OMJ), to request and load both job seeker and employer data.CB.5.2The 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.CB.5.3The System must automatically create a basic intake record with data, including but not limited to, name, address, date of birth and social security number.CB.5.4The System must manage synchronization of new seeker or update existing seeker record.CB.5.5The 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.CB.5.6The 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.CB.5.7The 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.CB.5.8The System must provide a real time feed of job seeker activity/services data to OhioMeansJobs.CB.6 Comprehensive Assessment and Services B.6.1The System must have a Case Management module that enables case management of individual job seekers eligible for services in federal and/or state programs. CB.6.2The 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.CB.6.3The 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.CB.6.4The System must provide at a minimum separate work queues for the petitions, service delivery, and contract staff. CB.6.5The System must provide the ability to track case worker assignments and performance based on unique identifier, e.g. staff ID and by program.CB.6.6The 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.CB.6.7The 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.CB.6.8The System must have the capability to add/update/delete job seeker information.CB.6.9The System must allow for a common assessment and career planning that help guide career pathways to employment (e.g. Comprehensive assessment, IEP, TABE).CB.6.10The 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.CB.6.11The System must provide for seeker tracking mechanisms, individual service plans, individual opportunity plans, and tracking of services.CB.6.12The System must provide the ability for follow up activities for all programs including identification of mandated (e.g. 1 year, follow up) activities.CB.6.13The System must provide configurable alerts, including but not limited to, 30/60/90 day follow up, no service provided and/or no activity.CB.6.14The System must have the ability to track TANF certification and eligibility as needed.CB.6.15The 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.CB.7 Case Intake and EligibilityB.7.1The 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.CB.7.2The System must complement the 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.CB.7.3The 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).CB.7.4The System must provide an automated solution to identify eligibility across multiple programs and allow for dual enrollment where appropriate.CB.7.5The 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); andOptional: Ohio Family Assistance (SNAP, TANF, OWF, CCMEP).CB.7.6The System must provide for participant eligibility determinations with all data elements as required by the federally sponsored Workforce Innovation Opportunity Act.CB.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.1The 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.CB.8.2The System must fully integrate the training provider module with case management.CB.8.3The 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.CB.8.4The 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.CB.8.5The 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).CB.8.6The System must have the ability to pull in WIET training providers/program data into the case management system (Individual Training Account).CB.8.7The System must have the ability to identify and track providers at a local and state level. CB.8.8The System must have the ability for provider to register their training institution (demographics and pertinent Ohio based standards/criteria and performance measures).CB.8.9The System must have the ability for providers to enter program data.CB.8.10The System must have the ability for the providers to appeal (provider data, program data, performance).CB.9 Employer ServicesB.9.1The System must interface with the feature that provides an Employer Management component which is responsible for employer registration, follow up with employers, and their recruitment needs.CB.9.2The System must provide the ability for state, county, and local partners to input and view information about employers, job orders, and services provided. CB.9.3The 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.CB.9.4The 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.CB.9.5The System must provide authorized staff the ability to access all employer records to provide assistance and monitoring.CB.9.6The System must provide the ability to assign and track lead staff contacts to each employer record.CB.9.7The 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. CB.10 Fiscal ManagementB.10.1The 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.CB.10.2The System must have the ability to track and report financial information for vendors.CB.10.3The System must have the ability to limit, track and manage financial information for an individual, and facilitate processing of training invoices.CB.10.4The 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.CB.10.5The System must provide the ability to select multiple funding sources per service.CB.11 Communication, Forms and NoticesB.11.1The System must have the ability to schedule and track appointments and/or provide an intuitive calendar option.CB.11.2The System must have the ability for referrals with alerts from program to program (example: Trade to LE or LE to WIOA) which alerts staff.CB.11.3The System must have the ability for referrals from local area to local area/local partner and/or county to county which alerts staff.CB.11.4The System must provide e-mail functionality.CB.11.5The 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.CB.11.6The 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.CB.11.7The System must provide robust case notes functions, including case note templates and spellcheck.CB.11.8The System must allow staff to administer (add/modify/delete) notes to a participant’s or employer's record.CB.11.9The System must create notes automatically based on system and OWD program business rules. These notes must be uniquely identified as ‘system generated’ notes.CB.11.10The System must provide the ability for private and public case notes.CB.11.11The 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. CB.11.12The System must have the ability to build electronic forms that can be integrated back to the system of record.CB.12 ReportingB.12.1The 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. CB.12.2The 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.CB.12.3The 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.CB.12.4The Reporting Module must produce both on-demand and regularly scheduled reports. CB.12.5The 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.CB.12.6The 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.CB.12.7The 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.CB.12.8The 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.CB.12.9The 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.CB.12.10The Reporting Module must provide standard WIOA and Title I federal mandated reports (all Titles, Veterans, etc.).CB.12.11The 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.CB.12.12The 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.CB.12.13The 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.CB.12.14The 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.). CB.12.15The System must allow staff to run parameterized on-demand reports. CB.12.16The System must allow staff to maintain a run-time schedule for reports.CB.12.17The System must produce reports based on staff defined intervals (daily, weekly, monthly, etc.).CB.12.18The System must allow staff to select the delivery method for available reports. CB.12.19The System must allow staff to pre-define the number of records to be returned per page on a report. CB.12.20The System must provide logical navigation for multi-page reports. CB.12.21The System must allow staff to retrieve on-demand reports real time or in overnight batch mode. CB.12.22The System must regulate the production of on demand report based on system usage/performance. CB.12.23The System must notify staff when an on-demand report is available when the generation of the report was delayed due to system usage/performance. CB.12.24The System must automatically route report results to staff (both regularly scheduled reports and on-demand reports). CB.12.25The System must display reports in multiple formats (i.e. table, chart, graph). CB.12.26The System must allow staff to save reports in various formats including XLS, DOC, PDF, CSV, TXT, and Image files. CB.12.27The System must provide a printable view of reports (with no truncating report data). CB.12.28The System must archive reports. CB.12.29The 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.CB.12.30The System must have the ability to customize each report based on all the data fields, performance year/quarter, and date range.CB.12.31The System must have the ability to create ad hoc reporting by Workforce Investment Board, State, and provider level.CB.12.32The system must have the ability to track, monitor, and report on common performance measure to ensure compliance. CB.12.33The system must have the ability to create/integrate reports across all Title I and Title 3 Programs.CB.13 UsabilityB.13.1The 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.CB.13.2The System must contain an integrated on-line trouble-shooting facility inclusive of all common errors and probable resolutions.CB.13.3The System must support multiple navigation controls (e.g. menu, icons, keyboard shortcuts, right-click).CB.13.4The System must support hover-over controls to display functional descriptions and context-sensitive help.CB.13.5The System must support the ability to automate and?prepopulate fields to decrease duplicative staff entries.CB.13.6The 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. CB.13.7The System must provide real-time integration of common data (i.e. biographical/demographic) for all implemented programs in order to eliminate redundant data entry.CB.14 System AdministrationB.14.1The 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.CB.14.2The System must support role-based authentication and allow authorized users to manage roles and user profiles on-line.CB.14.3The 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.CB.14.4The 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.1For 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). CB.15.2For 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.CB.15.3For 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. CTable C: InterfacesRequirement Type definitions: C is a critical component of the system. D is a desirable component of the system.OWST InterfacesTypeOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentC.1 Interfaces C.1.1The 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).CC.1.2The 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 .1.3The System must support real time feed/Nightly file with UI System of Record that includes unemployment claimant data, including RESEA per .1.4The 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. CC.1.5The 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 .1.6The System must support real time data exchange with external systems (e.g. other state agencies, federal government, vendors). CC.1.7The System must provide an electronic interface with occupational coding .1.8The 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, .1.9The 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- .1.10The System must interface with America's Labor Market Information (ALMIS) Database, InfoUSA's ALMIS Employer Database and other sources of labor market .1.11The System must provide address and/or zip code verification via interface with a service or USPS. CC.1.12The System must provide an electronic interface with Ohio Department of Administrative Services for printing/mailing .1.13The 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. CC.1.14The System must have a real time feed from OhioMeansJobs (OMJ) of registered Job Seekers and to create job .1.15The 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 .1.16The System must support a real time feed and nightly file with Ohio UI System that includes unemployment claimant data, including RESEA per .1.17The System must support daily Uploads from Ohio Counties (contains demographics, services of registered individuals). CC.1.18The 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 .1.19The System must provide a real time feed from the Workforce Inventory Education & Training (WIET) .1.20The System must provide a real time feed from the County Finance Information System (CFIS).CC.1.21The System must provide a real time feed/nightly file with ERIC for wage .1.22The System must interface with the U.S. Veterans Affairs information to automatically validate the veteran target group. (WOTC option).CC.1.23The System must interface with the Opportunities for Ohioans database to validate voc rehab target group. (WOTC option)CC.1.24The System must interface with the WOTC address locator to automatically validate eligibility for WOTC designated target groups. (WOTC option)CC.1.25The System must interface with Maximus Ticket to Work system to validate eligibility for WOTC. (WOTC Option)CC.1.26The System must interface with Ohio Department of Corrections to validate .1.27The System must provide daily feed to OAKS or CFIS that includes information to make payment to providers, employers or other .1.28The System must provide a feed to the Office of the Attorney General that includes information concerning certified debt for .1.29The System must provide a daily feed to the Treasurer of State that includes warrant information required to pay benefits to individuals. CC.1.30The System must provide a quarterly feed to Alda (Ohio State University longitudinal database).CC.1.31The System must provide a real time feed from the Ohio Child Support System (SETS).CC.1.32The 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 .2 Interface InteroperabilityC.2.1The System must automatically export data from the system in multiple formats (e.g., csv, fixed length ASCII, tab delimited).CC.2.2The System must automatically import data into the system in multiple formats (e.g., csv, fixed length ASCII, tab delimited).CC.2.3The System must automatically maintain external system information for interfaces (e.g., connection strings, file paths).CC.2.4The System must automatically transmit/receive imported/exported data through multiple methods (e.g., file output, web service, single and batch transactional (e.g., PIRL). CC.2.5The System must automatically generate and execute scripts to import and export data. CC.2.6The System must automatically present a result list for data imports and exports (e.g., success or failure, time started, time completed). CC.2.7The 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). CC.2.8The System must automatically isolate records within a file that contain an error condition and process the file excluding the error records. CC.2.9The System must automatically create a report of records that could be successfully processed within a batch file. CC.2.10The System must automatically restart an interface transmission from a specific point (e.g., restart at failed record, restart from beginning). CC.2.11The System must automatically associate information received via interface with the line-of-business record which generated the information request. CC.2.12The 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.CTable D: Common RequirementsRequirements Type definitions: C is a critical component of the system. D is a desirable component of the mon System RequirementsTypeOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentD.1 Security and RecoveryD.1.1Application access must be logged and have a viewable audit trail(s). CD.1.2Changes to user permissions must be logged and have a viewable audit trail(s). CD.1.3Access to audit trail logs must be able to be restricted to approved administrators. CD.1.4Application 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; andBefore and after value of the changed item.CD.1.5The following application change event(s) must be logged: Changes to individual permission level;Changes to role membership;Changes to role permissions; andChanges to access to application functions. CD.1.6The System Administrator must be able to control access to audit trail logs. CD.1.7Passwords and User IDs must be able to: Protect sensitive data;Restrict access to only those intended;Meet Federal/State/Agency Security Standards; andBe able to be encrypted.CD.1.8Applications and systems must adhere to ODJFS Policy regarding Access to Networks, Systems, Computers, Databases and Applications.CD.1.9Applications and systems must adhere to ODJFS Policy regarding Access to Protected Data Resources. CD.1.10End-user software applications, or components thereof, must not require privileged, super-user or administrator mode in order to function properly. CD.2 Identity ManagementD.2.1The System authentication and authorization must be by individual user. User account information must be stored securely. Users may belong to groups and roles. CD.2.2The System must provide the system administrators with the capabilities to define different roles with different privileges. CD.2.3The System must provide for hierarchical roles. CD.3 System Performance and CapacityD.3.1The system must provide performance-optimization capabilities. CD.3.2The 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. CD.3.3The 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.CD.3.4The 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.CD.3.5The 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.CD.3.6The System must support 300 simultaneous staff users with an average of 15 seconds think time between page requests.CD.3.7The System must support 1 million participant records per year.CD.3.8The System must maintain 10 years of participant and employer history.CD.4HostingD.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. CD.4.2The proposed solution delivers standard reports/information useful for assessing the overall status, operation and debugging of the solution.CD.5Single Sign-onD.5.1The 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). CD.5.2The system must address the requirements in supplement 3. CD.6Work FlowD.6.1The System must automatically distribute work items to the appropriate staff using staff's profile and configurable work item attributes. CD.6.2The 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. CD.6.3The System must allow staff to adjust the distribution of work items. CD.6.4The System must allow staff to search, select, and assign selected work items to a staff inbox. CD.6.5The System must allow staff to view work items distributed by team, role, area and staff members. CD.6.6The System must automatically alert staff when a work item is approaching or past the work item's due date of completion. CD.6.7The System must allow staff to search for work items using single or multiple search criteria. CD.6.8The System must allow staff to limit the number of results returned for a work item search. CD.6.9The System must automatically display the results of a search for work items. CD.6.10The System must automatically display the search criteria used for the image/work item search on the search result screen. CD.6.11The System must allow staff to select a work item or multiple work items to perform a selected action. CD.6.12The System must allow staff to add, edit and delete notes to an image or work item. CD.6.13The System must automatically update the status of a work item each time an action is taken on the work item. CD.6.14The System must automatically distribute work items requiring approval to designated staff. CD.7Help SearchD.7.1The System must provide context sensitive, on-demand help. CD.7.2The System must provide immediate, searchable and relevant on-line access to all Workforce Development policy and procedure manuals and new updates. CD.7.3The System must provide an online general subject index, process and procedure guide and field-level help guide. CD.7.4The System must provide a full glossary of all Workforce Development terms. CD.7.5The System must allow staff to perform online searches using a variety of parameters (text, dates, etc.). CD.7.6The System must allow staff to perform keyword searches. CD.7.7The System must allow staff to combine multiple search criteria using logical operators such as ‘AND’, ‘OR’, BETWEEN’ and 'LIKE'. CD.7.8The System must allow staff to sort search results returned data. CD.7.9The System must allow staff to filter search results. CD.7.10The System must allow staff to search and retrieve records (or logical groups of records) matching compound search criteria. CD.7.11The System must provide query searching capabilities that can be used to search within a result set. CD.7.12The System must allow staff to perform advanced searches to filter search results. CD.7.13The System must allow staff to configure the number of returned search results. CD.8Security User Interface D.8.1The System must enforce security roles at a function level to determine users (internal/external) ability to enter, update, view and/or delete. CD.8.2The 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. CD.8.3The System must allow staff to establish "user profiles" consisting of one or more security roles from which individual staff may inherit privileges. CD.8.4The System must automatically log security events (e.g., failed/successful login attempts, amendment of user rights, inactivation of users). CD.8.5The System must automatically log staff accessing confidential personal information.CD.8.6The 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. CD.8.7The System must provide logical navigation and menuing for each screen. CD.8.8The System must be flexible with dynamic displays of information, data capture, edits/validations, instructional messages etc. based on security roles. CD.8.9The System must pre-populate data on screens (eliminate redundant/duplicate data entry). CD.8.10The 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. CD.8.11The System must automatically display a progress indicator to users for all processes requiring multiple steps or screens. CD.8.12The System must automatically display a time-out indicator to users prior to timing them out of system.CD.8.13The System must adhere to all Agency and State security policies and procedures.CD.8.14The System must be capable of offering historical tracking features when critical business information is modified so it can be referenced for future use. CD.8.15The 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. CD.9General D.9.1Must provide testing and training environments which are routinely updated with functionality additions and fixes that reflect the most current version of solution.CTable E: Program Specific RequirementsProgram Services RequirementsThe following section depicts program specific requirements and provides program specific capabilities which supplements the above Table B: OWST Business Requirements.TypeOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentE.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: WIOA/Final_Rules_Resources.cfm.E.1.1The 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.CE.1.2The System must have the ability to view program progress in the form of a dashboard-visual representation by county of program results.CE.1.3The System must have the ability to select multiple funding sources per paid service. CE.1.4The System must have the ability to upload certified worker data in multiple formats (.xls, .csv, etc.) into the case management system (system of record).CE.1.6The 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.CE.1.7The 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.CE.1.8The 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.CE.1.9The 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. CE.1.10The System must support a real time feed from OhioMeansJobs (OMJ) of registered Job Seekers.CE.1.11The System must have daily uploads from Ohio Counties (contains demographics, services of registered individuals). CE.1.12The 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.CE.1.13The 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.DE.1.14The System must have a real time feed from the Workforce Inventory Education & Training (WIET) system.CE.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 WIOA/Final_Rules_Resources.cfm, and Ohio Administrative Code: by State Law Comprehensive Case Management Program (WIOA Youth)See the common criteria section for additional Program RequirementsE.2.1The 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.CE.2.2The System must provide the ability to view program progress in the form of a dashboard-visual representation by county of program results.CE.2.3The 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.CE.2.4The System must have the ability to dual enroll customers in multiple programs with the ability to view all programs. CE.2.5The System must have the ability to select multiple funding sources per paid service.CE.2.6The System must have the ability to track hours for customers who are TANF work required and validate them weekly.CE.2.7The System must have the ability to upload certified worker data in multiple formats (.xls, .csv, etc.) into the case management system (system of record).CE.2.8The system must have the ability to capture and offer eligibility, dual enrollment, track and monitor services, job placements and 12 months of follow up.CE.2.9The 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.CE.2.10The 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. CE.2.11The System must have roles with hierarchy to include the ability to mark cases confidential.CE.2.12The System must provide case load view for staff and supervisors.CE.2.13The System must support a real time feed from OhioMeansJobs (OMJ) of registered Job Seekers.CE.2.14The System must support a daily upload from Ohio Counties (contains demographics, services of registered individuals).CE.2.15The 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.CE.2.16The System must support a real time feed from the Workforce Inventory Education & Training (WIET) system.CE.2.17The System must support a real time feed from the County Finance Information System (CFIS).CE.2.18The System must restrict access to special grant programs to only those the users granted the correct user role.CE.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: System must connect the RR Employer/Event with each individual in Case Management system to track services and activities through re-employment. CE.3.2The System must have the ability to allow in-state and out of state employers to be listed in the database.CE.3.3The System must be able to retain all WARN details on each company.CE.3.4The System must be able to track services given to WARN companies.CE.3.5The System must have the ability to track by impacted company (i.e. layoffs, closings).CE.3.6The System must be able to obtain a list of affected workers and track from WARN to employment.CE.3.7The 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.CE.3.8The System must support document scanning and retrieval to accept the Survey notes in the case where they are done via hard copy.CE.3.9The System must provide Veterans Priority of Service. Please describe how your system prioritizes veterans in this context. CE.3.10The 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. CE.3.11The System must provide a centralized database/Repository for easy reporting. This repository will be accessed by a wide variety of state and local entities. CE.3.12The System must support archiving data for retention, then purge data after 7 years. CE.3.13The 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). CE.3.14The System must incorporate the Survey Questions by allowing data to come into the new Case Management database and specific screens. CE.3.15The System must connect the RR Employer/Event with each individual in Case Management system to track services and activities through re-employment. CE.3.16The System must connect the RR Employer/Event with Employer Services provided to the employer by location. CE.4 VeteransVeterans' workforce services alleviate unemployment and underemployment for veterans and other eligible persons. E.4.1The System must distinguish DVOP and LVER staff, services, and activities. CE.4.2The System must support generating an Employment Plan with Goals.CE.4.3The System must support a separate Veterans Assessment.CE.4.4The System must have the ability to add goals to the Employment Plan.CE.4.5The 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.CE.4.6The System must have the ability to select "Significant Barriers to Employment" (more than 1).CE.4.7The 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) CE.4.8The System must have the ability to track military branch of service of veteran to include National Guard and reserve components. CE.4.9The System must have the ability to designate and track Military Occupations with available crosswalks to O Net Codes.CE.4.10The System must have the ability to designate and track Military Spouses of Active Duty military (Non-JVSG).CE.4.11The System must have the ability to designate and track HVRP veterans.CE.4.12The System must have the ability to designate and track eligible persons.CE.4.13The System must make Vet forms available online.CE.4.14The System must have online Job Ready Worksheet that is editable until the case exists (Ohio will provide the template).CE.4.15The System must be able to Terminate a veteran anytime.CE.4.16The System must have VA Chapter 31 Indicator on the Employment Plan and Caseload view.CE.5 RESEA and UCRSRecipients 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. E.5.1The 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.CE.5.2The System must have the ability for staff to sort and select individuals by county for RESEA or UCRS services.CE.5.3The System must have the ability to receive and track multiple dates/rescheduled RESEAs by individual/claim id (self-scheduler).CE.5.4The 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.CE.5.5The System must support a feed to OMJ that includes the UCRS and RESEA status/indicator.CE.5.6The System must support a feed to Ohio UI System that includes UC claim id, UCRS and RESEA status/indicator.CE.5.7The 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.CE.5.8The 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.CE.5.9The 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.CE.5.10The System must have separate work queues service delivery staff and supervisory/administrative staff.CE.5.11The System must serve as the single repository/source for program reporting purposes.CE.5.12The System must provide a feed to the State of Ohio print shop to generate and mail correspondence to individuals.CE.5.13The System must have the ability to conduct work through the various systems and databases used to run the program.CE.5.14The System must have the ability to view program progress in the form of a dashboard-visual representation by county of program results.CE.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: E.6.1Must 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. CE.6.2The system must be capable of tracking the universal customer from registration through follow up. CE.6.3The Employment Plan must have the functionality to capture Self- directed Services (via interfaces) to include Staff Assisted Career services. CE.7Re-Entry (REO) System must have self-service and manual functionality in separate application (outside case management system). CE.7.2The System must have current jobs data available for individual to find by county (doesn’t contain contact data). CE.7.3The System must be accessible from correctional institutions (One Stops to provide and assist prior to release).CE.7.4The ability to specifically identify and track incarcerated individuals more clearly.CE.8Migrant 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.? E.8.1The System must be capable of allowing Monitor Advocate track and follow the details of each Migrants activities. CE.8.2The System must have a separate MSFW Assessment. CE.8.3The 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.CE.8.4The 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.CE.9 Foreign Labor Certification FLCForeign 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. 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.CE.9.2The System must have the ability to store all forms, track the FLC related employers, and job postings in the database. CE.9.3The System must have a reporting database in the case management system to ensure tracking and monitoring.CE.9.4The 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. CE.9.5The System must have the ability to edit, change pages of a PDF submission as well as separate or combine documentation submitted.CE.9.6The System must have the ability to view job orders, job posting, qualification information as well as any other information needed. CE.9.7The 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.CE.9.8The System must support application tracking.CE.9.9The 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.CE.9.10The System must maintain electronic files of all documentation received as well as notifications and determinations (ex. Current FileNet).CE.9.11The 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.CE.9.12The 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.CE.9.13The System must have the ability to track guest workers who have been referred and hired by either the H2A or H2B employers.CE.9.14The System must have the ability to create an extract for DOL reporting specific to FLC performance measures.CE.10 ApprenticeshipApprenticeships?teach high-level skills for today's workplace by combining classroom and on-the-job training.E.10.1The System must support Apprenticeships - logging actual customers going through the apprenticeship program from beginning to end. CE.10.2The System must support reporting used to audit businesses- making sure the facility is up to code.CE.10.3The System must support the interface with WIET for registered Apprenticeship employers.CRequirement Type definitions: C is a critical component of the system. D is a desirable component of the system.Table F: Trade Program Specific Requirements - OptionalProgram Services RequirementsThe following section depicts program specific requirements and provides program specific capabilities which supplements the above Table B: OWST Business Requirements.TypeOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentF.1 Trade - OptionalTrade?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: TRADE 20 CFR, Part 618; 20 CFR, Part 617; 29 CFR, Part 90; TEGL 5/15F.1.1The 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.CF.1.2The System must provide a feed to OMJ that includes individual worker information and BRI status.CF.1.3The 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.CF.1.4The System must support a daily feed to OAKS or CFIS that includes information to make payment to providers, employers or other entities.CF.1.5The System must support a feed (frequency to be determined) with the Ohio UI System that includes information regarding appealed determinations.CF.1.6The System must provide a feed to the Office of the Attorney General that includes information concerning certified debt for collection. CF.1.7The System must provide a daily feed to the Treasurer of State that includes warrant information required to pay benefits to individuals.CF.1.8The 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). CF.1.9Separate work queues for the petitions, service delivery, and contract staff.CF.1.10The 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.CF.1.11The System must support a feed to OMJ that includes individual worker information and BRI status.CF.1.12The 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. CF.1.13The System must support a daily feed to OAKS or CFIS that includes information to make payment to providers, employers or other entities. CF.1.14The System must support a feed (frequency to be determined) with Ohio UI System that includes information regarding appealed determinations. CF.1.15The System must support a feed to the Office of the Attorney General that includes information concerning certified debt for collection. CF.1.16The System must support a daily feed to the Treasurer of State that includes warrant information required to pay benefits to individuals. CF.1.17The System must build database tables for TAA petitions, waivers, and TAA contract data.CF.1.18The System must have the ability to upload certified worker data in multiple formats (.xls, .csv, etc.) into the case management system (system of record).CF.1.19The System must have the ability to add individual worker data to the case management system.CF.1.20The System must have separate work queues for the petitions, service delivery, and contract staff.CF.1.21The System must support a determination and appeal structure for training contracts, job search allowances, relocation allowances, and other TAA benefits.CF.1.22The System must support ODJFS staff in handling 30-day follow-up requirements.CF.1.23The System must support ODJFS staff in managing waivers.CF.1.24The System must maintain WIOA integration information and ability to refer to WIOA and Wagner-Peyser.CF.1.25The System must have queue to assign new customers - multiple at a time.CF.1.26The System must assign cases automatically transfer to identified caseload to specific Case manager.CF.1.27The System must provide an alert to case manager of new cases.CF.1.28The System must have the ability for case manager to view caseload and sort by multiple data fields. CF.1.29The System must have the ability for supervisor to view caseloads of all team members and individual case manager and sort by multiple data ranges. CF.1.30The System must have the ability to transfer cases between case managers.CF.1.31The System must identify of petition information. CF.1.32The System must identifier for what benefits customer is utilizing.CF.1.33The 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.CF.1.34The System must have the ability to upload documents.CF.1.35The System must send out automatic TDP letters for newly assigned customer. CF.1.36The System must support ability to complete transportation worksheet. CF.1.37The System must have the ability to enter waivers, benchmarks and progress reports to feed into benefit system.CF.1.38The System must have the ability to submit training/OJT contracts and modifications.CF.1.39The System must have the ability to submit relocation and job search application. CF.1.40The System must have the ability to send out manual benchmarks. CF.1.41The System must have the ability to keep track of training contracts and modifications.CF.1.42The System must have assessment to feed into employment and/or training plan. CF.1.43The System must have the ability for a case manager to email customer updates, requests, or documents.CF.1.44The System must have a conversational notepad for case manager and supervisor to communicate back and forth.CF.1.45The System must have the ability for supervisor to mark areas of concern. CF.1.46The 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.CTable 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 TypeOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentG.1 WOTC - OptionalWork Opportunity Tax Credits?(WOTC) are tax incentives?for businesses hiring individuals from certain groups of disadvantaged job seekers who?face significant barriers to employment. G.1.1The System must have the capability to identify seekers that hits a specific target group for WOTC.CG.1.2The 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.CG.1.3The system must have the ability to be yearly modify with the selected WOTC target groups based on DOL policy.CG.1.4The System must provide an interface with Ohio Dept. of Corrections (ODRC) - weekly contains released individuals.CG.1.5The 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.CG.1.6The 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). CG.1.7The System must upload completed forms from Employer on individuals for which incentives were given individually or in bulk. CG.1.8The 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. CG.1.9The System must generate/view electronic notices to employers/agents; internal view of notices.CG.1.10The System must be able to deny an application that is considered a re-hire or duplicate and generate a notice.CG.1.11The System must be able to deny an application when the target group is no longer valid and generate a notice.CG.1.12The System must be able to retain multiple deficiency reasons. CG.1.13The System must be able to retain multiple denial reasons. CG.1.14The 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.CG.1.15The System must have the ability for employers/agents to add, update, and view power of attorney authorizations - provide approval by WOTC team.CG.1.16The 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.CG.1.17The 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.CG.1.18The System must be able to view job order, job poster, qualification information as well as any other information needed. C13Table H: CFIS 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.TypeOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentH County Finance Information System – OptionalH.1.1CFIS 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. DEach 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.2CFIS Data Interfaces Requirements1. 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. CH.1.3OhioMeansJobs (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 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.DH.1.4Resource Room Configuration Needs1. 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.DH.1.5Fiscal 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 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. DH.1.6CCMEP 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 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.DH.1.7Reports1. 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.D14Table 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.Program Services RequirementsThe following section depicts program specific requirements and provides program specific capabilities which supplements the above Table B: OWST Business Requirements.TypeOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentI Labor Market Information - OptionalLabor 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.1The 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.CI.1.2The System must provide an electronic interface with the Ohio Bureau of Labor Market Information.C15Table J: Document Imaging 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.TypeOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentJ Document Imaging Features - OptionalLabor 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.1The System must provide for the ability of an authorized user to upload documents to a Case that can be sued for various programs.CJ.1.2The 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.CJ.1.3The 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.CJ.1.4The System must allow authorized users to upload multiple documents at once. Multiple documents may be associated to one Intake or Case.CJ.1.5The System must provide the ability to enter comments associated to a document.CJ.1.6The 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.CJ.1.7The System must provide a visual cue while the system processes the document upload.CJ.1.8The System must provide a warning message when the user attempts to upload a document that is too large or in the wrong format.CJ.1.9The System must provide a confirmation when the document upload is successful.CJ.1.10The 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.CJ.1.11The System must provide the ability to cancel a document upload prior to the Save action.CJ.1.12The System must provide a centralized location to search and manage documents.C16Table 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.Program Services RequirementsThe following section depicts program specific requirements and provides program specific capabilities which supplements the above Table B: OWST Business Requirements.TypeOfferor ResponseCheck Applicable BoxNarrativeCore CapabilityConfiguration OptionRequires DevelopmentK Job Seeker Interface Features - OptionalODJFS 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.1The 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.CK.1.2The 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.CK.1.3The 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.CK.1.4The 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.CK.1.5The System tablet application must have the capability of capturing and storing signature.CK.1.6The System must provide the ability to recreate an image of the form from the data collected including signatures where applicable.CK.2 Trade Tablet InterfaceThis section deals with the mandatory forms and user data collection for this program.K.2.1The 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.CK.2.2The 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.CK.2.3The 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.CK.2.4The 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.CK.2.5The System tablet application must have the capability of capturing and storing signature.CK.2.6The System must provide the ability to recreate an image of the form from the data collected including signatures where applicable.CService Level Agreements - Operations17.1Parties and TimelineThis 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 CatalogueThe Contractor will provide the following services to the State of Ohio:ServiceDescriptionExamplesUser 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 supportAnswer queries about applications.Receive and document bug reports.Collect and document requests for changes.Share status of requests.Problem CorrectionBring 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 plete root cause analysis.17.3DeductionsA 5% deduction from the Contractor’s monthly invoice for the month in which one or more of the SLA levels were not met. 17.4ReportingThe 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.1Weekly Status ReportThe 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; andAction items across.17.4.2Monthly Review MeetingMetrics 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; andCapturing agreements and disagreements and items needing escalation.17.4.3Quarterly Review MeetingA 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.); andSLA changes will be tracked by version number and date.17.4.4Reporting Service LevelsTypeMeasurementWeekly Status ReportDelivered at not less than seven calendar day intervalsMonthly Status ReportDelivered at monthly intervals and not less than two business days before scheduled review meetingQuarterly Status ReportDelivered at quarterly intervals and not less than five business days before scheduled review meeting17.5User Support and Problem CorrectionThese 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.1Prioritization ApproachService 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 CodeDefinition1Severity 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.2Severity 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.3Severity 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.4A problem has diminished routine application functionality or performance. 17.5.2Application Function TypeThe 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 TypeDescriptionExamplesCriticalThese 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 InterfacesUrgentThese application functions are important to business productivity but are not critical Workforce Development services nor critical to ODJFS reputation.Other System InterfacesReportingProvider ListRoutineThese applications support productivity but are not essential to business effectiveness.17.5.3Response and Resolution TimesSeverity 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 CodeInitialResponseEstimation ResponseSubsequent ResponsesResolution115 minutes 2 hoursEvery 30 min.8 hours230 minutes 2 hoursEvery 2 hours2 business days31 hour8 hoursDaily10 calendar days41 hourNext business dayWeekly60 calendar daysInitial 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.4Response and Resolution Service LevelsIf 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.TypeMeasurementProblem ResolutionLess than 90% of problems are resolved in the prescribed resolution interval.Response/EstimateLess than 90% of Initial Response, Estimation Response, and Subsequent Response times are met. Maximum Problem AgingNo problem is older than 180 days.17.5.5Application AvailabilityAvailability 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 LevelBusiness Hour AvailabilityOff-Hour AvailabilityScheduled Down-TimeDefinitionMonday-Friday 8 am – 5 pm ESTMonday-Friday 5:01pm-7:59 am EST; Sat. and Sun.Monday-Friday 10 pm – 6 am ESTCritical99.5% 99.5% To Be mutually agreed uponUrgent99% 98% To Be mutually agreed uponRoutine98% 98% To Be mutually agreed uponAny additional outages must be scheduled and approved by ODJFS at least two weeks in advance, unless there is an emergency.1575.6Application Availability Service LevelsIf 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. TypeMeasurementCritical Application AvailabilityAvailability falls below 99.5% for more than 2 days of the month during regular business hours.Urgent Application AvailabilityAvailability falls below 99% for more than 2 days of the month during regular business hours. Routine Application AvailabilityAvailability falls below 98% for more than 2 days of the month during regular business hours.17.5.7Application Responsiveness Service LevelsOnline 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.TypeMeasurementApplication ResponsivenessMore than 5% of transactions complete (via State network) > 4.0 seconds Application ResponsivenessMore than 1% of transactions complete in > 10.0 seconds ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download