+ Request for Information

RFI Number: RFI Title: RFI Issue Date: FY17- 68 Research Administration Software April 12,2017 RFI Due Date and Time: Monday, May 1, 2017 at 3:00 PM (EST) Number of Pages (including cover): 12

INSTRUCTIONS TO INTERESTED PARTIES Return Responses by Mark Face of Envelope/Package:

Hand or Courier Delivery to:

THE UNIVERSITY OF TOLEDO RFI Number: FY17-68 PURCHASING SERVICES RFI Due Date: May 1, 2017 Learning Resource Center, 2nd Floor, Room 2190B Attn: Sharon Hunt 2801 EAST SCOTT PARK DRIVE TOLEDO, OH 43607 TOLEDO, OHIO 43614-5807 Special Instructions:

*ONE ORIGINAL* AND a Digital Copy submitted US Postal Mailing Address: on flash drive. THE UNIVERSITY OF TOLEDO PURCHASING SERVICES, MS 460 Attn: Sharon Hunt 2801 W. BANCROFT ST. TOLEDO, OH 43606

INTERESTED PARTIES MUST COMPLETE THE FOLLOWING and RETURN WITH RFI RESPONSE Name/Address: Authorized Signatory:

Phone Number: Fax Number:

Federal I.D. Number: E-mail Address:

1 2

State Certified MBE I.D. Number: (if applicable) Ohio EDGE Certification Number:

(For More Information see the Ohio State Web Site) (For More Information see the Ohio State Web Site http://das.ohio.gov/eod/EODMBEOff.htm http://das.ohio.gov/eod/EODMBEOff.htm

TABLE OF CONTENTS

1. Introduction...... 2 1.1 University Overview and Background Material...... 3 1.1.1 Definition of Terms and Functional Areas...... 3 1.2 ERP and Research Administration Software (RAS) Landscape...... 5 2. Project Background...... 5 2.1 Objectives...... 6 2.2 High-Level Scope...... 6 3. Invitation to Respond...... 7 3.1 The University of Toledo Contacts...... 7 3.2 Confidentiality and Legal Statements...... 7 3.3 Variations to Responses...... 7 3.3.1 Partial Responses...... 7 3.3.2 Group Responses...... 7 4. RFI Timeline...... 7 4.1 Schedule of Events...... 7 4.2 RFI Questions and Clarifications...... 8 5. RFI Instructions for Responses...... 8 5.1 Response Format...... 8 5.2 RFI Response Submission...... 8 6. Post-response Process...... 8 6.1 Evaluation...... 9 TECHNICAL RESPONSE...... 10 Section A — General Requirements...... 10 VENDOR RESPONSE – TO BE COMPLETED BY VENDOR...... 10 Vendor Profile and Demographics...... 10 What Functional Areas from Section 1.1.1 are addressed?...... 10 Ability to Meet UT’s RAS Objectives in Section 2.1...... 11 Overall Architecture of the Proposed System...... 11 Cost estimates...... 11 Section B — Business Requirements...... 12 Questionnaire on the Functional Requirements of the Application...... 12 Functional Requirements Questionnaire...... 12

RFI FY 17-68 Research Administration Software Page 2 1. Introduction

1.1 University Overview and Background Material

The University of Toledo (UT) became a member of the state university system of Ohio in 1967. UT and the Medical University of Ohio merged in July 2006 to form the third-largest public university in the state. The University is accredited by the Higher Learning Commission. The two campuses (Main Campus and Health Sciences Campus) are a few miles apart, with the Health Sciences Campus housing the College of Medicine and medical school, much of the College of Pharmacy and Pharmaceutical Sciences, the College of Nursing, and the UT Medical Center, a Level 1 trauma center. UT is home to about 20,000 students and some 6,500 fulltime faculty and staff, and is one of the largest employers in Ohio. UT offers more than 300 undergraduate, graduate and professional programs at 14 colleges. Colleges include Arts and Letters, Business and Innovation, Education, Engineering, Exploratory Studies, Graduate Studies, Health & Human Services, Honors, Law, Medicine and Life Sciences, Natural Sciences and Mathematics, Nursing, Pharmacy and Pharmaceutical Sciences, and University College.

UT is also transforming the regional economy through the UT’s Rocket Innovations and LaunchPad Incubation program which helps commercialize university research and support spinoff companies.

The most active colleges and professional schools in sponsored research activities are Medicine and Life Sciences, Engineering, and Natural Sciences and Mathematics. Though not a large research university, UT presents research administration challenges that are quite broad and diverse, with grants and contracts from hundreds of sponsors through dozens of funding arrangement types. Examples of the range of activities to be supported include environmental and Great Lakes projects, on-site research at NASA Glenn, industry-funded material testing, multi-site clinical trials, and the more commonly-known NSF, DOE and NIH multi-year projects. The range and complexity of proposals developed and awarded at UT is not unlike a very large research institution and include export controlled research and technology development.

The Office of Research & Sponsored Programs is headed by the VP of Research, and is staffed on both campuses with 6 grants coordinators (one position vacant); 3 compliance and contract people (one position vacant); 1 grant writer; 2 business manager / admin assistants; 2 directors; one Associate VP, one VP. Additional staff support Tech Transfer, technology commercialization, and IRB, IACUC and IBC administration.

UT has declined in the NSF rank of sponsored research expenditures from #160 to #190 in recent years, and lost significant staffing in research administration. It is now ramping up to manage anticipated growth, from the current level of about $40M to a goal of $80M by 2023 (according to the draft strategic plan as of March 2017). Additional metrics on proposals, awards, and compliance activity are available by request.

RFI FY 17-68 Research Administration Software Page 2 1.1.1 Definition of Terms and Functional Areas

COI: Conflict of Interest. COI functionality comprises tracking financial interests per investigator, as well as tracking disclosures per investigator per project (funded or unfunded). The COI process includes review and documentation of determinations (e.g. no management plan necessary, disallowed or management of conflicts) and involves reviewer and committee functions.

GAS: Grants Accounting System. Client-Server application developed in- house by UT IT for the Grants Accounting department to manage post- award functions not covered by Banner, such as invoicing, F&A redistribution, and support for the investigator-friendly award budget monitoring system (mySP). It supports tracking of post award information as well as post award reporting. The invoicing and financial reporting functionality is currently in transition, moving to Banner with a homegrown invoice management and tracking application.

Global: Data or mechanisms that are shared across the functional areas of the Research Enterprise. Examples include a departmental hierarchy to drive routing, an area that tracks Personnel Training from multiple sources, and a unified list of Sponsors and Organizations.

IACUC: Institutional Animal Care and Use Committee. IACUC functionality comprises investigator development of an application to perform animal research leading to a protocol; administrative and committee review of the application; creation of determination letters and revision requests; investigator development of amendment and renewal of applications; tracking of internal auditing; maintaining committee membership and schedule; generation of agendas and meeting minutes.

IBC: Institutional Biosafety Committee. IBC functionality comprises investigator development of an application to perform bio-hazardous research leading to a protocol; administrative and committee review of the application; creation of determination letters and revision requests; investigator development of amendment and renewal of applications; tracking of internal auditing; maintaining committee membership and schedule; generation of agendas and meeting minutes.

IRB: Institutional Review Board. IRB functionality comprises investigator development of an application to perform human research leading to a protocol; administrative and committee review of the application; creation of determination letters and revision requests; investigator development of amendment and renewal of applications; tracking of internal auditing; maintaining committee membership and schedule; management of study documentation; generation of agendas and meeting minutes.

mySP: My Sponsored Programs. mySP is a website which provides investigators access to view basic information about awards, as well as financial and labor details. Data is drawn from RSP, GAS and Banner. Reports include budget versus expenses, labor payroll detail, expense detail, monthly reporting, cash received, and obligations. Investigators can see their own award information; administrative personnel can search for awards by investigator and award number.

RFI FY 17-68 Research Administration Software Page 3 Pre-award: Pre-award functionality comprises opportunity identification, proposal development and endorsement, budget development and approval, proposal submission, award negotiation, technical/progress reports, amendments and modifications, subcontracts out, correlation of projects with compliance status (e.g. foreign persons restrictions, COI management, export control measures, technology plans, investigator training, human subjects and animal research approvals).

Post-award: Post-award functionality comprises review and approval of personnel actions and expenditures to ensure compliance with budget and award restrictions; processing of invoices, financial reports, subcontractor payments and all other related financial and equipment reporting required by the individual sponsor; assisting investigators in tracking and documenting cost share and monitoring effort reporting; producing NSF R&D expenditure reports and A-133/Uniform Guidance audit reports; train investigators on rules and regulations as well as institutional policies and procedures.

RAS: Research Administration Software: the entire suite of functionality sought in this RFI as described in the areas above, from COI through Post-Award.

RSP: Research & Sponsored Programs. Refers to both the office/department and the existing research administration system. The system is web-based and was built in house.

UT: The University of Toledo

RFI FY 17-68 Research Administration Software Page 4 1.2 ERP and Research Administration Software (RAS) Landscape

UT uses Ellucian Banner (currently version 8, moving soon to 9) for HR, Student, and Finance.

UT’s Reseach and Sponsored Programs department currently uses a SQL-based, web-accessible research administration application (RSP) developed in-house, for tracking submissions and awards, and as a data source for submission and award reports. It also supports basic tracking of IACUC, IRB, and IBC protocol submissions, as well as Personnel Training, compliance committee management and other globally necessary information such as a sponsor/vendor hierarchy.

UT has two IRB committees: a Social-Behavioral-Education committee (SBE) and Biomedical committee (Biomed). Both have been using the KC IRB module for over a year, but have significant issues with the functionality and interface.

The IACUC and IBC committees and processes are managed with a combination of lifecycle forms for protocols with Outlook Tasks for review process tracking and documentation. Basic administrative data is held in RSP which allows for management of committee members and meetings as well as “starter” documents for meeting agenda and minutes.

The Grants Accounting department uses a SQL-based, client-server application (GAS), also developed in house. GAS interfaces with Banner to create the grant; data from Banner is currently imported into the GAS database, allowing it to invoice awards and provide the financial information to present in the mySP website.

Conflict of Interest (COI) disclosures are collected in a separate SQL- based web-accessible interface that is closely tied to the RSP database for funded research. For unfunded IRB research, collection of COI disclosures remains a paper process utilizing a printable form. Reporting tools include a web-based, investigator-friendly award/budget monitoring tool, MySP, which pulls information from Banner, GAS, and RSP. Microsoft Access is for used for ad-hoc querying and some canned querying/reporting by a small group of administrative users. Various Crystal reports fill other gaps.

2. Project Background

The UT research enterprise is re-booting in two senses: 1) A relatively new university administration is pledging to boost sponsored research beyond previous highs of ~$75M/year from its current level of ~$40M in awarded dollars in FY16. It is widely understood that inefficiencies, processing delays, and redundancies in the current system are impeding research activity and causing faculty frustration, and that the support infrastructure and better communication across units must be enhanced to achieve the ambitious goals of research growth stated in the strategic plan.

RFI FY 17-68 Research Administration Software Page 5 2) UT is re-booting after spending several years pursuing the implementation of an open-source consortium solution (Kuali Coeus) intended for the entire research enterprise (pre- and post-award, compliance areas). The dissolution of the KC Foundation and dissatisfaction with the user interface, primarily about the IRB module, were major reasons to reconsider that direction. A survey of Ohio universities did not indicate consensus around a single off-the-shelf solution. As five years have passed since the previous system evaluation, a review of currently available software solutions is the next prudent step.

UT is open to integrating solutions from multiple vendors, with the goal of implementing the best products for each functional area. UT’s Information Technology (IT) department will consider playing a key role in integration of different products.

2.1 Objectives

This RFI's objective is for the University of Toledo to gather responses from a variety of vendors and/or consultants to plan for an effective and efficient RFP. The application(s) to be implemented will enable the organization to update research administration software (RAS) to:  Provide greater functionality, convenience, and transparency for investigators and internal endorsement reviewers (e.g. chairs, deans, sponsored programs office)  Provide better integration of compliance and grant tracking  Provide better record/document storage and retrieval across functional areas  Provide more efficient development and processing of grant proposals, budgets, and awards  Provide easily accessible and reportable data on grant and research activity  Provide more efficient development, review, administration and tracking of compliance areas such as IRB, IACUC, IBC and COI

An incomplete list of types of integration sought:  Data from one functional area is available in other areas.  Reports may draw from multiple functional areas.  Personnel data (training, salary) are available for use in all functional areas.  Proposals and Awards may be tied to related compliance records

UT recognizes that it may require solutions from multiple vendors to fill the broad scope of functionality sought and that UT IT may be central in

RFI FY 17-68 Research Administration Software Page 6 integrating those solutions. Through this RFI, UT hopes to learn about solutions that may be combined either by vendors or by UT in-house IT expertise.

2.2 High-Level Scope

UT seeks information on solutions to any and all of the scope of RAS as described in the definitions section 1.1.1 to meet the objectives in 2.1.

Excluded from the scope of this RFI are the following:

 Invention disclosures and patents, tracked by Technology Transfer.

 Functions currently filled adequately by Banner (award invoicing is currently being transferred to Banner) Potentially or partially in scope:

 Capability of working directly with NIH ASSIST, grants.gov S2S; NSF FastLane;

 Identification of funding opportunities, and integration with faculty expertise.

 Material Transfer Agreements tracking and routing

3. Invitation to Respond

UT invites interested parties that meet the qualifications listed in this document to submit responses regarding their product(s) and related service offerings. All information shall be submitted in the format stipulated in this RFI.

3.1 The University of Toledo Contacts

Should you have any questions or need clarification regarding this RFI, please contact the Purchasing Contract Manager below, noting the preferred method of communication Purchasing Contract Manager: Sharon Hunt, Ph: 419.530.8716. Email Address: [email protected] (preferred method of contact)

3.2 Confidentiality and Legal Statements

Confidentiality: The information contained in this RFI should be considered confidential to The University of Toledo and should be treated by the Responders as confidential. The information contained herein is to be used by each Responder only for the purpose of preparing a response to this RFI.

RFI FY 17-68 Research Administration Software Page 7 3.3 Variations to Responses

3.3.1 Partial Responses The University of Toledo will accept informational responses for part of the scope defined in its requirements. Vendors are invited to notify the UT contact person by April 17, 2017, of their intent to submit a partial response, specifying clearly what part will be submitted.

3.3.2 Group Responses The University of Toledo invites group (more than one vendor or vendor- consultant) responses, and requests that vendors concerned notify the UT contact person no later than April 17, 2017.

4. RFI Timeline

Vendor responses to this RFI will be accepted by 3:00 PM EST on May 1, 2017. All information submitted by the vendor will be used for evaluation purposes only.

4.1 Schedule of Events  RFI released to vendors April 12, 2017.  RFI Questions due by 12:00 PM on April 18, 2017.  Response to Questions posted by 5:00 PM on April 19, 2017  RFI responses due May 1, 2017 at 3:00 PM (EST).

4.2 RFI Questions and Clarifications

The Q&A period is intended to provide vendors with an opportunity to gather data from UT that will assist in creating their RFI Response.

5. RFI Instructions for Responses

Vendors are asked to address all information specified by this RFI. All questions must be answered completely. UT reserves the right to verify and clarify any information contained in the vendor's RFI response, and to request additional information after the RFI response has been received.

Marketing brochures included as part of the main body of the bid response shall not be considered. Such material must be submitted only as attachments and must not be used as a substitute for written responses. In case of any conflict between the content in the

RFI FY 17-68 Research Administration Software Page 8 attachments and a vendor's answers in the body of the response, the latter will prevail.

5.1 Response Format

Vendors must complete this document where indicated by the words “TO BE COMPLETED BY VENDOR” beginning in the Technical Response Section A and the Questionnaire file provided with this RFI.

5.2 RFI Response Submission

Vendors' proposals should be mailed following the guidelines established on the cover page for hard copy and digital submittal.

Please note that it is the vendor's responsibility to ensure that the response and all other required documents are received at the address named above by the closing date specified above.

UT is aware that information contained in the response indicates the vendor's current operations. Therefore, use of this information shall be confined to this request and will be treated as confidential.

Vendors shall bear all costs associated with preparing and submitting responses to this RFI and the subsequent evaluation phase. UT will, in no way, be responsible for these costs, regardless of the conduct or outcome of the prequalification process.

6. Post-response Process

After receipt of all informational packets and prior to the determination of the possible service providers to which an RFP may be submitted, UT may initiate discussions with one or more suppliers should clarification of content of the RFI response become necessary. Supplier(s) may be asked to make an oral presentation and/or product demonstration to clarify their RFI response or to further define their capabilities.

6.1 Evaluation

An evaluation of proposed products will generally include an assessment of the viability of those products in the RAS application market. Evaluation will also include the fit and integration with related UT infrastructure, system environments and business applications. Technical merits and features will be reviewed against the requirements identified in the general and functional requirements sections of this document.

RFI FY 17-68 Research Administration Software Page 9 [The balance of this page is left blank intentionally]

RFI FY 17-68 Research Administration Software Page 10 TECHNICAL RESPONSE

Section A — General Requirements

Description of RAS Strategy and Project Objectives

UT seeks to implement an integrated software solution for a wide range of research administration functions described in section 1.1.1, Definitions and Functional Areas that meets most or all of the objectives described in section 2.1 Objectives.

UT is open to integrating solutions from multiple vendors, with the goal of implementing the best products for each functional area. UT’s IT will consider playing a key role in integration of different products.

UT is agnostic on deployment style (e.g. SaaS, on-premises/managed on-premises) but intends to have reporting capabilities combining functional areas.

VENDOR RESPONSE – TO BE COMPLETED BY VENDOR

Vendor Profile and Demographics

Provide a brief history of your company, how it is organized, and how its available products and resources will be used to meet UT’s requirements. The vendor shall submit the following information: 1. The company's official name and address. Also indicate what type of entity it is — for example, a corporation or a partnership. 2. The name, address, email and telephone number of the person who receives correspondence and who is authorized to make decisions or represent the vendor. Please state his or her capacity within the company. 3. The total number of years the vendor has been in business and, if applicable, the number of years under the present business name. 4. The number of years that the vendor has been providing the application(s). 5. A description of the vendor's operations: facilities, business and objectives, and the number of employees. 6. A brief summary of vendor's product portfolio, including number of distinct products sold. 7. The product profile for the product the vendor is proposing, including: how many maintenance-paying customers and time in market.

RFI FY 17-68 Research Administration Software Page 11 8. References: Provide a maximum of three (3) client references, similar in scope, in which the vendor has provided services. Also include a brief project overview, contact name, phone number, and email address for verification purposes.

What Functional Areas from Section 1.1.1 are addressed? Vendor should describe the functional areas included in the proposed solution.

Ability to Meet UT’s RAS Objectives in Section 2.1 Vendor should describe its ability to meet UT’s objectives here.

Overall Architecture of the Proposed System

Vendor should answer the following questions about platform and integration:

1. Please describe a typical hardware/software/database architecture for implementation of your product. Diagrams and alternative implementations are welcome as attachements to the RFI response.

2. What comes out of the box to help with integration? E.g., data transfer tools (Excel files, templates, scripts), help and instruction tools, configurable web help, other?

3. Please describe a typical client/device configuration for your product. Are there OS, browser, or plug-in requirements?

4. What middleware is required for the product?

5. Describe the integrations and structure of preferred implementations of your product. E.g., reporting layers, APIs, DMZs, scripted data imports and exports.

6. Does your product provide keyword searching capability? If so, please explain.

Cost estimates

UT is seeking information on the cost of a typical implementation. It is understood that any numbers provided are strictly estimates and may change at any time for any reason. Please address the following items with best estimates from previous experiences/implementations. 1. Total cost of the project, or costs broken down by modules or defined functions

RFI FY 17-68 Research Administration Software Page 12 2. Typical timeline from contract signature to project completion, with appropriate phase breakouts if desired.

3. Typical staffing needs: how many people from each UT functional area will be needed, the anticipated background and responsibilities of these individuals, and what will the typical burden be?

RFI FY 17-68 Research Administration Software Page 13 Section B — Business Requirements

Questionnaire on the Functional Requirements of the Application

This questionnaire will be used to document the vendor's proposed solution(s) to UT's functional requirements.

In the Capability section, vendors can choose from five options to indicate their compliance with each requirement (see Table 1).

Table 1. Vendor Capabilities Declared

Option Capabilities 0 Functionality not provided 1 Functionality provided; requires customized integration with third-party solution 2 Functionality provided by the vendor, but requires customization 3 Functionality provided seamlessly by third-party solution 4 Functionality provided as standard

When giving responses, the guidelines below should be followed. The comments column is provided for clarification, when necessary.

Vendors are cautioned not to indicate functionality as "included in standard offering" when, in fact, that particular feature is in development. Instead, vendors indicate Option 0, “Functionality not provided,” and use the comments column to indicate the expected date that such a feature will be made available.

 Functionality not provided: Not included in the proposed application.

 Functionality provided; requires customized integration with third-party solution: Vendor has established a relationship with a business partner to provide this functionality, but it needs customizing or working around.

 Functionality provided by the vendor, but requires customization: The functionality can be accomplished with the vendor's products, but some customizing or working around is required.

 Functionality provided seamlessly by third-party solution: The vendor has established a relationship (for example, as an OEM) with a business partner to provide this functionality, which is fully integrated (data, process, application) with the proposed solution and requires no customizing or integration development.

 Functionality provided as standard: The vendor provides the functionality from its own code base. No customizing or working around is required. Configuration may be required.

RFI FY 17-68 Research Administration Software Page 14 Functional Requirements Questionnaire Please see the Excel attachment for the functional requirements questionnaire, which must be completed in full and returned in Excel format

RFI FY 17-68 Research Administration Software Page 15