Enterprise Business System Software

for

Research Administration

at

MSU

Peter D. AsquithSenior Advisor VPRGS & VPLCTProfessor of Philosophy

(http://ebsp.msu.edu)

MSU is engaged in Enterprise Business System Projects to update its softwaresupport for its functional activities with financial, human resource and research administration components being the current focus. Initially the project involved only the financial and human resource components with the research administration component being added in the summer of 2006. For each of these components MSU is assessing its functional and data needs prior to selecting and then implementing the chosen software products.

In addition to these specific business systems there are other components that have application across all of these systems – enterprise information stewardship and business intelligence. Other systems are likely to be added inThe future, e.g., a student information system.

The following slides focus on research administration.

The MSU Enterprise Business System Projects (EBSP)

Given the importance of obtaining external funding to support the institution’s research activities there is a need to have a research administration system that both meets the complexities of the functional needs of research administration –

• Faculty proposal development through submission to funding agencies• Grants administration both fiscal and compliance including closeout• Reporting functions for sound management

and at the same time meets the requirements of an enterprise level system - • “Industrial Strength” -- supported centrally in terms of servers, back-up,

intrusion and virus detection and protection, and integration with other systems

• Protection of Information• Business Continuity and Disaster Plan for Recovery• Quality Control Plan for Identification and Correction of Problems• Accessible System

The Research Administration Component of EBSP

• Are locally developed, oriented to the needs of the business process owner, and vary in effectiveness.

• Variable in ability to connect to central data repositories and with each other.

• Incomplete in dealing with a research proposal from conception to completion.

• Developed utilizing a variety of technologies including some that are either outdated or lack scalability.

• Don’t contain standardized data element formats

• Can simply be an EXCEL spreadsheet stored on an individual machine or a network drive.

Overview of Current State of University Level MSU Research Administration Systems

Preliminary & Incomplete Inventory of University Level Systems

System/Tool Owner Purpose Developer

       

Grant Proposal System OVPRGS Support the development, submission and review of proposals for internal funding competitions and the internal review of limited submission external funding opportunities

DECS

IRB ORA Support the submission of protocols for approval, facilitate the work of the review committees and maintain an inventory of all protocols.Individual training records.

ORCBS

ORCBS ORA Databases of relevant individual training records and laboratory records.

ORCBS

Export Control ORA Inventory of Proposals for which an export control compliance document has been filed.

 

eTransmittal CGA Electronic version of the transmittal sheet.A beta version is available for the CGA web site at: www.cga.msu.edu/pl/portal/default.aspx

CGA

Inventory (Cont.)

CGA Salary Budget Builder CGA Enables lookup up of salaries, determination of start date and multiple year salary expenses with an inflation factor. Calculated fringes.

CGA

CGA Intermediate Budget Form CGA Provides a budget sheet with standard categories and formula to assist in calculating totals and multiple year budgets.

CGA

Proposal Information Switchboard CGA Provides entry point for transmittal data, ability to run reports.

CGA

All Search CGA Ability to search the CGA proposal and Blue Run databases in a variety of flexible ways with a degree of built in intelligence.

CGA

Blue Run CGA Award summary screen that ties dates, amounts, title, PI, agency, specific notes, ledger balance, F&A rate and basis, etc.– useful for approval of expenditure transactions and general account questions.

CGA

AR -- Accounts Receivable   CGA A system to track and age invoices for payment on CGA accounts.

CGA 

Subcontract  CGA Post Award Management for Subcontract tracking

CGA

Payroll CGA View payroll expenses on CGA accounts

CGA

Inventory (Cont.)

SER -- Semester Effort Reporting

CGA Provides documentation for salary and/or effort commitments to federal and State of Michigan projects. Effort report summary info for CGA and select department administrators.

CGA

FAR Log (Federal Acquisition Regulation)

CGA An index of frequently used FAR contract clauses and options/strategies for negotiation and acceptability per MSU policy.

CGA

CGA Autobill  CGA Invoice creation based on a pre-established schedule rather than on a reimbursable basis.

CGA

LOC -- Letter of Credit-- Reporting (NSF & NIH)

CGA Assists with the quarterly NSF and NIH expenditure reports.

CGA

Contract Log CGA  Provides a web view of information on the status of the contract negotiation process.

CGA

Participating in the Kuali Foundation project with investing partners Cornell, MSU, Indiana, Arizona and Colorado State with support from the Mellon Foundation to develop open source, database agnostic research administration (KRA) software based on the proprietary Coeus code base.

– Developing with partners rather than on one’s own brings more resources to bear both in terms of dollars but also talent.

– There will be greater familiarity with the software and realization of the requirements for implementation than with vendor purchased software.

– This eliminates being held hostage to vendor upgrade schedules and the necessity of vendor support.

– Opportunity to affect the development of the software in ways that will make it a better fit for MSU’s needs.

– Greater number of participating institutions potentially provides greater bargaining power with grants.gov development.

– Resulting commonality of basic business procedures across a greater number of institutions is potentially useful in audit situations.

MSU Research Administration Software Strategy

Coeus Consortium Membership

Have joined the consortium at the development institution level as a voting member of the various sub-committees – pre-award, post award, compliance and technical. This allows participation in determining the functionality to be added to Coeus.

Kuali Research Administration (KRA) ProjectAlong with other investing partners (Cornell, MSU, Indiana, Arizona andColorado State) and with support from the Mellon Foundation are providing three developers and participating in the writing of the functional specifications to develop this software which is based on Coeus code.

MSU Documentation and Assessment Documentation of the current business processes utilized in research administration at MSU. Conduct a current state analysis to determine deficiencies, possible improvements and desired future state.

The Research Administration Project – Three Components

Coeus

And

The Coeus Consortium

Coeus employs two different interfaces utilizing different technologies and designed to serve different purposes -- Lite and Premium.

Coeus Lite – Java Webstart is utilized to provide an interface that can be utilized by users on any platform by using their web browser. Functionality is provided in this web interface for the creation of the basic components of proposal, routing and submission to federal agencies. Coeus Lite allows:

• the end user the ability to create a proposal for submission to a sponsor using an intuitive interface.

• the investigator and other individuals to work concurrently on the proposal budget, narratives and the general data within the application.

• routing and review of the proposal by individuals in the approval chain for the institution.

• the submission of the proposal to Grants.gov. • investigators the ability to complete and submit a human subjects protocol if the

Coeus IRB module has been implemented. Coeus Lite makes training the majority of end users much easier since the interface is intuitive yet rich in functionality.

Coeus – Two Different User Interfaces

Coeus – Two Different User Interfaces (cont.)

Coeus Premium – This is a client/server interface that is graphically rich and icon driven. Considerable functionality is available in this interface that is not available in the alternative interface Coeus Lite. The Premium user interface to Coeus is designed for back office use. Within the Premium interface your functional and business level people can control the routing, business rules, rates, cost elements, unit hierarchy, IRB committee and meeting schedules and all the other functions needed to make Coeus a comprehensive research administration application.

Coeus Lite PortalNeed to logon prior to this screen.

Coeus Lite My Proposals with Proposal Selected

Coeus Premium Initial Screen

Coeus Icons and Menu Choices

Top row of icons remains the same throughout the application, but the bottom row changes depending upon the particular activity being undertaken.

Coeus Modules

Coeus Consists of nine different modules.

The Proposal Development Module

The Proposal Development Module has been designed to allow departmental administrators and investigators to construct full proposals from the desktop. First, the user is required to create a proposal shell, which includes the basic header information typically found on an institutional proposal routing form. Once this piece is done, work on the proposal can be distributed by function and managed through use of system roles. The Proposal Development Module also contains a robust tool for creating budgets. It stores all approved Employee Benefit, Facilities and Administrative rates, inflation factors, and ensures compliance with the Cost Accounting Standards (CAS) by allowing the user to budget in the same manner in which expenditures will be incurred.

Coeus Modules – Proposal Development (Cont.)

After the budget has been created and the science appended, the

proposal is marked complete. The user then submits the proposal for

online approvals. The system applies business rules created at the

departmental, administrative office level and the centralized sponsored

projects office, securing appropriate approvals along the way. When

complete, the proposal will go through a final institutional review before

it is submitted electronically to those sponsors that can accept an

electronic proposal. Alternatively, the proposal can be printed for those

sponsors that will require a paper proposal. The Proposal

Development Module also is integrated with the Sponsor table (list of

all sponsors) and Rolodex table (list of sponsor contacts).

Coeus Modules

Institutional Review Board

The Coeus IRB module is the latest addition to the suite of modules which make up the Coeus application. The IRB module was designed by Coeus Consortium schools and incorporates the best practices of those institutes. The IRB module allows Coeus users to setup and maintain review committees, including the composition of the committees and the committee schedules. The application also allows investigators to create protocols, submit the protocols to a committee and receive communication during the review process throughout the protocol life cycle. With the addition of Coeus Lite the protocols can be created through any easy to use web- based interface. In addition, the protocol and proposal can be linked within the application, making the protocol information and the grant information easily accessible by the compliance, pre-award and post-award departments.

Coeus Modules

The Institute Proposal Module

The Institute Proposal Module contains those works that have been submitted to sponsoring organizations for funding. Where works in progress are stored and edited in the Proposal Development Module, only completed works are stored in the Proposal Module. Each proposal that has been officially submitted by the organization to the external sponsor is assigned a unique identifier. Through this identifier, the user can view basic data on funding source, title, department, principal investigators, and amount proposed. Also in this module, the user is able to generate a Current and Pending Support report for any investigator listed in the proposal. Current and Pending information can be downloaded in a variety of formats for subsequent modification to conform to individual sponsor requirements. Once a proposal is funded, the information in the Proposal Module forms the basis of the actual award.

Coeus Modules

The Award Module

The Award Module maintains detailed information on awards and subcontracts including a complete history of every change made to an award and subcontract from notice through closeout. The Coeus system stores all agency contacts (in the electronic rolodex), maintains all reporting requirements (financial, technical, property, patents), maintains the terms and conditions, required cost sharing, special reviews (animals, human subjects, biohazards, etc.), F and A rates (whether limited by agency or fixed for the life on Federal awards), as well as the required approvals for the equipment, foreign travel, and subcontracts.

Coeus Modules

The Subcontract Module

The Subcontract Module is maintained under the awards that fund the agreement and contains detailed information on sub-recipient agreements. Data in this module includes: the amount, the start and end date, the investigator at the receiving organization, other administrative contacts, and all required closeout information. Historical information is captured as the subcontract is modified to allow tracking of change orders to the subrecipient agreement. Additionally, funds released from incoming invoices are also maintained.

The Negotiation Module

The Negotiation Module allows the Sponsored Programs office to track negotiations for individual proposals. It provides administrators with tools to keep notes and track the progress of the negotiation, facilitates sharing of electronic files, and generates status reports for negotiations.

Coeus Modules

Person Module

The Person Module is the central repository for information regarding employees and students that may be associated with proposals or awards. The person module allows for multiple degree records to be stored, allows for biosketch information in Word and PDF format to be stored, allows the user to produce current and pending support lists for any investigator, and tracks all required training.

The Conflict of Interest Module

The Conflict of Interest Module allows authorized users to check and maintain all Conflict of Interest and financial interest disclosures that may compromise professional judgment in carrying out research work. Principal Investigators (PIs) can maintain their financial interest disclosures in the Coeus database, and the Sponsored Programs Office can track the apparent conflicts through their resolution and maintain the required annual Conflict of Interest disclosure reports for individual PIs on existing NIH and NSF proposals and awards.

Coeus Modules

The Report Tracking Module

The Report Tracking Module tracks due dates and maintains the report status for required reports for an award. This module has sophisticated grouping and sorting capabilities to allow custom reports to be generated directly from the application that are relevant to the PI, department administrators and/or central offices. Three views are available at the click of an icon for the most useful views of the data. These views can be subsequently modified to tailor the report to the desired user specification. Once the reports are sorted and grouped, the information can be downloaded.

Coeus Consortium Memberships

• A Basic Member will have access to all developments produced by the Coeus Consortium during the course of their membership.

• A Development Member will be entitled to participate in Consortium meetings to be held on a set schedule to discuss future development activities and to assist in the identification of detailed specifications of those development activities. The Development Member will also be entitled to propose a specific functionality or a specific infrastructure project related to the Coeus product on payment of additional sums (i.e., in excess of the basic $25,000) subject to the review of the Steering Committee and the final decision of the Program Director.

Coeus Consortium Memberships (cont.)

• The third level of participation will be the Steering Member who will provide a greater amount of financial support and, in addition to being able to allocate a portion of its membership fee towards a specific focused Infrastructure Project, will be entitled to designate an individual to serve on a Steering Committee that will assist the Program Director with the establishment of Program priorities and initiatives. The Program Director will receive and be responsive to comments from and the consensus of the Steering Committee in selection of initiatives for implementation. In this manner, Steering Members will assist the Program Director with the choice of new developments. The Steering Committee will meet as often as necessary to determine Program issues, but at least semi-annually. The Steering Committee will support the Program director in preparing an annual summary of Program activities for all Members of the Consortium.

• The fourth level of participation will be Industry Member which, because of its commercial interests, will also provide a greater amount of financial support. The Industry Member will be entitled to the same program participation as the Steering Member.

List of Coeus Members

Steering Members:Brown University Cornell University Dartmouth College Drexel University Johns Hopkins University Massachusetts Institute of Technology

Memorial Sloan-Kettering Cancer Center Purdue UniversitySUNY -- Buffalo University of Maryland - Baltimore University of Maryland - College Park Wayne State University Weill Cornell Medical College Yale University

Development Members:Indiana University Michigan State UniversityThe Jackson Laboratory University of Rochester Vanderbilt University

Basic Members:

Arizona State University Baylor University Boston University Medical Campus Colorado State University Education Development Center Incorporated George Mason University Kent State UniversityLoyola Marymount UniversityMaine Medical Center Research InstituteMississippi State University Murray State University Princeton University Rutgers University

Stevens Institute of TechnologyUniformed Services University of the Health Sciences University of California - Berkeley University of California - MercedUniversity of California-Riverside University of California-San Diego University of CincinnatiUniversity of Medicine and Dentistry of New JerseyUniversity of Mississippi Medical Center University of Tennessee University of Texas - Austin Whitehead Institute Biomedical Research

Coeus Organizational Structure and MSU Participation

As a development level member of the Coeus consortium MSU has a vote on the Coeus sub-committees, but not on the Coeus Consortium Steering Committee. The sub-committees draw up the functional specifications for enhancements and determine the priorities within the functionality covered by the sub-committee. The Steering Committee determines overall priorities.

Subcommittees and current MSU representation are:

Pre-award Post-award Compliance TechnicalLisa Oliva Renee Dolan Linda Triemer Ajay PatelStacy Salisbury Ann Spalding Kristen BurtTeresa Thomas Craig O’Neill Karalyn BurtPeter Asquith Laura Baese

Basic members can participate in sub-committee deliberations, but have no vote.

Coeus: Pros and Cons

Pros:History of UtilizationUse by Variety of InstitutionsFunctional Specifications Determined CollectivelyS2S with Grants.GovActive, engaged User CommunityNot commercial vendor product

Cons:ProprietaryOracle DependentDeveloped PiecemealStill MIT DependentClient/Server Architecture for PremiumPremium Utilizes Non-user Friendly IconsFew, if any, institutions have implemented the full set of Coeus Modules

The intent of the “kualification” of Coeus is to take advantage of the strengths and eliminate or ameliorate the disadvantages.

Why Start with Coeus?

• Satisfies the Mellon Foundation requirement to use an existing system.

• MIT was willing to provide the intellectual property rights to Coeus for this project.

• Is one of the most comprehensive of the existing systems.

• Is an actual working product that currently has selected modules in use by numerous institutions.

• Possibility of creating product supported by significant number of research institutions. The Coeus Consortium has 44 members.

More institutions means:

• Increased resources for future development.

• Resulting commonality of basic business procedures across a greater number of institutions is potentially useful in audit situations.

• Greater number of participating institutions potentially provides greater bargaining power with grants.gov development.

Kuali Foundation

And

Kuali Research Administration

Kuali

The Kuali Foundation is a non-profit organization responsible for sustaining and evolving a comprehensive suite of administrative software that meets the needs of all Carnegie Class institutions. Its members are colleges, universities, commercial firms and interested organizations that share a common vision of open, modular, and distributed systems for their software requirements.  The goal of Kuali is to bring the proven functionality of legacy applications and convert them to online services.

The Kuali Partners Program (KPP) is the means for any college, university, commercial, and other not-for-profit organization to get involved in sustaining and evolving the Kuali software and community. Kuali began in 2004 as a cooperative effort among 7 partners and an investment from the Mellon Foundation. It is beginning a transition from a 7 member, partner and foundation funded project to a self-sustaining organization funded entirely by its membership.

MSU is a partner in two of the Kuali projects – Kuali Research Administration (KRA) and Kuali Financial System (KFS).

Overall Kuali Foundation Structure

Kuali Project (Module) Organization

MSU KRA Project Participants

Project Board

Bruce Alexander, Director for the University’s Enterprise Business System Projects and Associate Director for Administrative Information Services

Ex-Officio Members of the Extended Board

Dan Evon, Director, Contracts and Grants

David Gift, Vice-Provost Libraries, Computing and Technologies

Peter D. Asquith, Professor of Philosophy and Senior Advisor to theVice-President Research and Graduate Studies and to the Vice-Provost Libraries, Computing and Technology

MSU KRA Project Participants (Cont.)

Functional Council

Peter D. Asquith, Professor and Senior Advisor to VPRGS and VPLCT

Dan Evon, Director, Contracts and Grants

Technical Council

Ajay Patel, Administrative Information Services

Subject Matter Expert (SME) Subcommittees Representatives

Proposal & Budget Development

Peter D. Asquith, Professor and Senior Advisor

Lisa Oliva, Research Administration Workgroup Lead EBSP System Project

(KRA Module co-Lead SME)

Stacy Salisbury, Contacts and Grants Administrator

Teresa Thomas, Lead Analyst Research Admin

Carolyn Wemple, Analyst Research Administration

MSU KRA Project Participants (Cont.)

Subject Matter Expert (SME) Subcommittees Representatives (cont.)

Award

Renee Dolan, Lead Analyst Research Admin

Craig O’Neill, Asst Director Contracts and Grants

Ann Spalding, Lead Analyst Research AdministrationLaura Baese, Contracts and Grants Administrator

IRB

Linda Triemer, Director Regulatory Affairs

Kristen Burt, ORA Education Program Coordinator

Karalyn Burt, SIRB Administrator

MSU KRA Project Participants (Cont.)

User Interface

Peter D. Asquith, Professor and Senior AdvisorLisa Oliva, Research Administration Workgroup Lead Enterprise

Business System Project (KRA Module co-Lead SME) Renee Dolan, Lead Analyst Research Administration

Craig O’Neill, Asst Director Contracts and GrantsCarolyn Wemple, Analyst Research Administration

MSU KRA Project Participants (Cont.)

Integration Team

Rochele Cotter, Director of Client Advocacy Office and EBSP Team Lead Enterprise Information

StewardshipVince Schmizzi, Assistant Controller and EBSP Team Lead

FinancePeter D. Asquith, Professor and Senior Advisor

EBSP Business Intelligence Liaison

Teresa Thomas, Lead Analyst Research Administration

Currently Anticipated KRA Development & Release Timeline

The initial two releases of KRA software – currently scheduled for July ‘08 and August ‘09 – will be translations of existing Coeus functionality to the new architecture and will not attempt to provide enhancements to Coeus functionality other than those that result naturally from the new architecture. The third release scheduled for Sept ‘10 will include the translation of the Coeus modules not included in Release 1.0 or Release 2.0 and an animal care and use module not currently in Coeus. The fourth release scheduled for October ‘11 will consist of compliance modules not currently contained in Coeus.

These project dates are all predicated on having the current complement of developer and SME resources available throughout the project and the relative accuracy of the development hour estimates without developed functional specifications. Changes for both the better or worse are possible.

Currently Anticipated KRA Development & Release Timeline (Cont.)

For Release 1.0 functional specification writing and coding are occurring

virtually simultaneously while for the modules in releases after the first

functional specification writing will occur in the development cycle prior to the

coding period for the module.

The next slide is a graphic representation of the timeline for the first three

releases followed by more eight more detailed descriptive slides on all currently scheduled releases.

KRA Development and Release Timeline

Current division into phases is based upon each of the original four partner institutions providing the full contingent of developers in the memorandum of understanding and no additional investing partners being added.

KRA Release 1.0 - July 07 - March 08 (Development) April 08 – June 08 (QA)

(Both the writing of functional specifications and coding will occur in this time frame.)

Shared Service (RICE) and Infrastructure Baseline Objects and Services:Unit HierarchyRolodexPersonOrganizationWorkflowSecurityRoleCode/Reference TableLocationSponsorCommitteeQuestionnaireCustom ElementCost Element

(Both the writing of functional specifications and coding will occur in this time frame.)

Proposal & Budget Development

Baseline Functionality:

Proposal Development

Proposal Budget Development

Submitted Proposal

Proposal Routing

Grants.gov Integration

KRA Release 1.0 - July 07 - March 08 (Development) April 08 – June 08 (QA)

KRA Release 2.0: July 07- June 08 Functional Specification DeterminationJuly 08- July 09 Development and QA

Institutional Review Board

Baseline Functionality:

Submission of protocols – new, continued, amended

Recording IRB deliberations and review of protocols

IRB notifications

IRB meeting agendas and committee minutes

Queries to look up approved protocols and training information

Special reviews and other committees

Records required Human Participants training

Committee creation and scheduling

Batch correspondence and correspondence generation

KRA Release 2.0: July 07- June 08 Functional Specification DeterminationJuly 08- July 09 Development and QA

Awards

Baseline Functionality:Award detailCost sharingIndirect costPayment scheduleSponsor funding transferApproved equipment and foreign travelAward closeoutPaymentMoney and end datesAward BudgetContactsAward templatesSpecial reviewsInvestigator credit splitNotice of AwardData feed and integration with financial system

KRA Release 2.0: July 07- June 08 Functional Specification DeterminationJuly 08- July 09 Development and QA

Conflict of Interest Baseline Functionality:

Conflict certifications for faculty, staff, and studentsTracking of disclosures, reviews, and decisionsSeparate financial disclosure information as confidential or non-confidential

Release 3.0:July 08 - July 09 Functional Specification DeterminationAugust 09 - September 10 Development and QA

Negotiations Baseline Functionality:

Record actions of negotiationsManagement reporting

Report Tracking Baseline Functionality:

Automatic generation of reporting deliverables and statusManagement reportingSubmission status

Subcontracts Baseline Functionality:

Subcontract detailFunding sourcesAmount informationSubcontract closeout and correspondenceContactsSubrecipient monitoring (A-133)Invoice routing and approval

Release 3.0:July 08 - July 09 Functional Specification DeterminationAugust 09 - September 10 Development and QA

Animal Care and Use

Enhancements:

Committee maintenance

Submission of protocols – new, continued, amended

Recording IACUC deliberations and review of protocols

IACUC notifications

IACUC meeting agendas and committee minutes

Queries to look up approved protocols and training information

Special reviews and other committees

Records require animal subjects training

Committee creation and scheduling

Batch correspondence and correspondence generation

Release 4.0:August 09- September 10 Functional Specification DeterminationOctober 10 – October 11 Development and QA

Bio-Safety ManagementEnhancements:

Submissions of MOU on biological materials, including select agentsSubmissions of MOU amendments and renewalsProduction of IBC minutesMonitoring of approved MOUReporting of non-complianceFacilities inspection

Export Controls / ITAR ManagementEnhancements:

Certification questionnaire with routing approvalOffice of Foreign Asset Control (OFAC) purchases

Chemical TrackingEnhancements:

Controlled substance program

Synchronization of Coeus and KRA

Since Coeus is still undergoing development it presents a moving target for KRA. Currently, (12/07) the production version of Coeus is 4.2.4 with 4.3 scheduled for release in January 08 and the set of enhancements for 4.4 in the process of being determined. Originally KRA was to convert Coeus 4.1, but each KRA module will be based on the Coeus version available at the time of KRA development of that particular module. In addition:

• Coeus and KRA will jointly write the functional specifications for those modules not currently existing in either system. When a current Coeus module is in a rudimentary state of development, the specifications to write a more robust module will be jointly developed.

• Coeus will adopt KRA architecture for future new development where ever possible.

• Coeus will move towards utilizing the services that will be the components of KRA RICE.

Screen Design Critique and Functional Testing

• Faculty and staff from the various investing partner institutions have been and are being asked to participate in design critiques of mock screens. MSU has had participants in all of the sessions to date. Past critiques have resulted in changes. Critiques for both proposal development and budget development screens will be held the end of January/beginning of February 08.

• Testing of small pieces of code have begun utilizing the SMEs who have been writing the functional specifications. There will be extensive testing during the quality assurance (QA) period utilizing scripts and a much broader audience.

Implementation

• The hope is to implement KRA Release 1.0 concurrently with the initial implementation of SAP HR and the Kuali Financial System (KFS). Implementation will be multiple events staged over the ’09-’10 fiscal year.

• KRA will require interfaces to the HR system for person data, to the CGA suite of systems currently used to manage awards and to the financial system to enable award accounting as well as budget building within the MSU framework.

• Implementation prior to the implementation of these other systems would require building interfaces to both the current systems HR and financial systems and to the new systems as well. This would both require scare resources and time gain, if any, would be minimal.

• Need to allow adequate period for training on the new systems before they are placed in production.

MSU Documentation

And

Assessment

Joining Coeus and being a KRA partner will not be a magic bullet

There are cases where Coeus code:

• Lacks functionality that MSU currently has, e.g., on line discussion in IRB review process.

• Does not have functionality that MSU does not currently have and is desired by MSU and partner schools, e.g., IACUC.

• Contains functionality that is at variance with current MSU business practice, e.g, a transactional COI system.

• While the initial phases of KRA will be based on Coeus code, it is barely more than “vaporware.”

• “Porting” from Coeus code to Kuali code is not just a technical activity, but requires an understanding and specification of the function to be carried out by the code.

Joining Coeus and being a KRA partner will not be a magic bullet (Cont.)

A determination needs to made if there are cases in which absolutely essential

functionality for a majority of the partner schools is missing.

MSU needs to be in a position to make compelling cases for the enhancements

needed to make KRA fully functional for MSU.

Productive and effective participation both in Coeus and KRA requires having

both a thorough and systematic understanding of MSU’s current research

administration processes and determining MSU’s desired future state.

Complexities

Both MSU and Kuali have been participants in developing the Kuali Financial System (KFS). While there are valuable lessons learned from the financial project, there are important and significant differences between a financial system and a research administration system that make creating a research administration system more difficult.• The set of individuals having ownership for the research administration

system is broader. Principle users of the financial system are accountants, budget officers and administrators whereas faculty will be a critical set of users for KRA. This is an important consideration in determining interface design.

• A research administration system ranges across a wide variety of disparate functions including proposal development, approval and submission, compliance, award management fiscal and otherwise, and award closeout.

• The standards for fiscal systems are well established whereas components of research administration are handled very differently by different institutions and legislation frequently specifies that something must be done not how it must be done.

Why Not Implement Coeus As An Interim Solution?

Some Modules Are Not Useful for MSU in Current Form:

• No on line discussion in IRB review process which MSU currently has.

• Contains functionality that is at variance with current MSU business practice, e.g., a transactional COI system.

Implementation Realities For Currently Useful Modules:

• Experience at other schools is that it takes approximately a year to build and test interfaces required for other systems (HR and Finance) to fully implement a module. Limited resources need to be devoted to long term solutions – not interim solutions – unless the benefits of implementing an interim solution outweigh the costs and disadvantages.

Why Not Implement Coeus As An Interim Solution? (cont.)

* Greatest potential increase in functionality would come from implementing the Proposal Module of Coeus, but that is also the module that is being developed for the first release of KRA. Anticipated time advantage gained by implementing the Proposal Module of Coeus ranges from 3 to 15 months before KRA Release 1.0 is anticipated to be implemented. Not adequate time to warrant users having to learn two different systems.

What Needs to Be Done?

Coeus

• Actively participate on Coeus sub-committees to help determine the future direction of Coeus. Enhancements to various modules of Coeus will become part of KRA.

KRA• Continue participating in the writing of the functional specifications for the various

modules of KRA.

• Participate in the governance activities involved in managing and determining the priorities of the KRA project.

• Participate in design critiques and test KRA modules as they become available.

What Needs to Be Done?

MSU

• Document the current research administration processes at MSU whether electronic or manual so that they can be analyzed by both the business process owner and other affected parties.

• Have the set of stakeholders participate in systematically determining the characteristics of the future desired business processes.

• Compare the functionality of Coeus (initial KRA functionality) with both MSU current functionality and desired future functionality.

• Develop detailed plans for the implementation of KRA including training and help.

• In light of anticipated KRA module delivery dates develop a coordinated interim plan for both the maintenance and gradual phasing out of the current internal MSU systems.

Importance of Documenting and Analyzing MSU’s Processes

Despite the fact that a considerable period of time will elapse prior to KRA actively developing some of these modules there is a need to keep working on MSU’s internal documentation and analysis of all of the areas of research administration.

• Developing a reasonable maintenance plan for MSU systems and the consideration of how “must have” enhancements are to be handled requires a better and more comprehensive understanding of the current set of MSU processes and systems.

• New investors to the KRA partnerships may suggest altering currently determined priorities and we need to be able to determine how the suggested alterations might impact our needs.

Importance of Documenting and Analyzing MSU’s Processes (cont.)

• Systematic documentation should be of assistance in both audit and accreditation situations.

• Having a comprehensive understanding of all of the needs will facilitate the writing of functional specifications applicable across a broader spectrum of research administration activities, e.g., committee or questionnaire.