1. Enterprise Business System Software for Research Administration at MSU Peter D. Asquith Senior Advisor VPRGS & VPLCT Professor of Philosophy

2. (http://ebsp.msu.edu)http://ebsp.msu.edu MSU is engaged in Enterprise Business System Projects to update its software support 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 in The future, e.g., a student information system. The following slides focus on research administration. The MSU Enterprise Business System Projects (EBSP)

3. 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

4. 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

5. Preliminary & Incomplete Inventory of University Level Systems System/ToolOwnerPurposeDeveloper Grant Proposal SystemOVPRGSSupport the development, submission and review of proposals for internal funding competitions and the internal review of limited submission external funding opportunities DECS IRBORASupport the submission of protocols for approval, facilitate the work of the review committees and maintain an inventory of all protocols.Individual training records. ORCBS ORADatabases of relevant individual training records and laboratory records. ORCBS Export ControlORAInventory of Proposals for which an export control compliance document has been filed. eTransmittalCGAElectronic 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

6. Inventory (Cont.) CGA Salary Budget BuilderCGAEnables lookup up of salaries, determination of start date and multiple year salary expenses with an inflation factor. Calculated fringes. CGA CGA Intermediate Budget FormCGAProvides a budget sheet with standard categories and formula to assist in calculating totals and multiple year budgets. CGA Proposal Information SwitchboardCGAProvides entry point for transmittal data, ability to run reports. CGA All SearchCGAAbility to search the CGA proposal and Blue Run databases in a variety of flexible ways with a degree of built in intelligence. CGA Blue RunCGAAward 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 CGAA system to track and age invoices for payment on CGA accounts. CGA Subcontract CGAPost Award Management for Subcontract tracking CGA PayrollCGAView payroll expenses on CGA accounts CGA

7. Inventory (Cont.) SER -- Semester Effort Reporting CGAProvides 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) CGAAn index of frequently used FAR contract clauses and options/strategies for negotiation and acceptability per MSU policy. CGA CGA Autobill CGAInvoice creation based on a pre- established schedule rather than on a reimbursable basis. CGA LOC -- Letter of Credit-- Reporting (NSF & NIH) CGAAssists with the quarterly NSF and NIH expenditure reports. CGA Contract LogCGA Provides a web view of information on the status of the contract negotiation process. CGA

8. 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

9. 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) Project Along with other investing partners (Cornell, MSU, Indiana, Arizona and Colorado 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

10. Coeus And The Coeus Consortium

13. 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

14. 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.

15. Coeus Lite Portal Need to logon prior to this screen.

16. Coeus Lite My Proposals with Proposal Selected

17. Coeus Premium Initial Screen

18. 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.

19. 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.

20. 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).

21. 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.

22. 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.

23. 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.

24. 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.

25. 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.

26. 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.

27. 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.

28. 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.

29. 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 University SUNY -- Buffalo University of Maryland - Baltimore University of Maryland - College Park Wayne State University Weill Cornell Medical College Yale University Brown University Cornell University Dartmouth College Drexel University Johns Hopkins University Massachusetts Institute of Technology Memorial Sloan-Kettering Cancer Center Purdue University University of Maryland - Baltimore University of Maryland - College Park Wayne State University Weill Cornell Medical College Yale University Development Members: Indiana University Michigan State University The Jackson Laboratory University of Rochester Vanderbilt University Indiana University Michigan State University University of Rochester Vanderbilt University

30. Basic Members: Arizona State University Baylor University Boston University Medical Campus Colorado State University Education Development Center Incorporated George Mason University Arizona State University Baylor University Boston University Medical Campus Colorado State University Education Development Center Incorporated George Mason University Kent State University Loyola Marymount University Maine Medical Center Research Institute Mississippi State University Murray State University Princeton University Rutgers University Murray State University Princeton University Rutgers University Stevens Institute of Technology Stevens Institute of Technology Uniformed Services University of the Health Sciences University of California - Berkeley University of California - Merced University of California-Riverside University of California-San Diego University of Cincinnati University of Medicine and Dentistry of New Jersey University of Mississippi Medical Center University of Tennessee University of Texas - Austin Whitehead Institute Biomedical Research University of California - Berkeley University of California-Riverside University of California-San Diego University of Cincinnati University of Medicine and Dentistry of New J University of Mississippi Medical Center University of Tennessee University of Texas - Austin Whitehead Institute Biomedical Research

31. 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-awardPost-awardComplianceTechnical Lisa OlivaRenee DolanLinda TriemerAjay Patel Stacy SalisburyAnn SpaldingKristen Burt Teresa ThomasCraig O’NeillKaralyn Burt Peter Asquith Laura Baese Basic members can participate in sub-committee deliberations, but have no vote.

32. Coeus: Pros and Cons Pros: History of Utilization Use by Variety of Institutions Functional Specifications Determined Collectively S2S with Grants.Gov Active, engaged User Community Not commercial vendor product Cons: Proprietary Oracle Dependent Developed Piecemeal Still MIT Dependent Client/Server Architecture for Premium Premium Utilizes Non-user Friendly Icons Few, 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.

33. 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.

34. Kuali Foundation And Kuali Research Administration

35. 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).

36. Overall Kuali Foundation Structure

37. Kuali Project (Module) Organization

38. 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 the Vice-President Research and Graduate Studies and to the Vice- Provost Libraries, Computing and Technology

39. 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

40. 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 Administration Laura Baese, Contracts and Grants Administrator IRB Linda Triemer, Director Regulatory Affairs Kristen Burt, ORA Education Program Coordinator Karalyn Burt, SIRB Administrator

41. MSU KRA Project Participants (Cont.) User Interface Peter D. Asquith, Professor and Senior Advisor Lisa 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 Grants Carolyn Wemple, Analyst Research Administration

42. MSU KRA Project Participants (Cont.) Integration Team Rochele Cotter, Director of Client Advocacy Office and EBSP Team Lead Enterprise Information Stewardship Vince Schmizzi, Assistant Controller and EBSP Team Lead Finance Peter D. Asquith, Professor and Senior Advisor EBSP Business Intelligence Liaison Teresa Thomas, Lead Analyst Research Administration

43. 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.

44. 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.

45. KRA Development and Release Timeline

46. 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 Hierarchy Rolodex Person Organization Workflow Security Role Code/Reference Table Location Sponsor Committee Questionnaire Custom Element Cost Element

47. (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)

48. KRA Release 2.0: July 07- June 08 Functional Specification Determination July 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

49. KRA Release 2.0: July 07- June 08 Functional Specification Determination July 08- July 09 Development and QA Awards Baseline Functionality: Award detail Cost sharing Indirect cost Payment schedule Sponsor funding transfer Approved equipment and foreign travel Award closeout Payment Money and end dates Award Budget Contacts Award templates Special reviews Investigator credit split Notice of Award Data feed and integration with financial system

50. KRA Release 2.0: July 07- June 08 Functional Specification Determination July 08- July 09 Development and QA Conflict of Interest Baseline Functionality: Conflict certifications for faculty, staff, and students Tracking of disclosures, reviews, and decisions Separate financial disclosure information as confidential or non-confidential

51. Release 3.0: July 08 - July 09 Functional Specification Determination August 09 - September 10 Development and QA Negotiations Baseline Functionality: Record actions of negotiations Management reporting Report Tracking Baseline Functionality: Automatic generation of reporting deliverables and status Management reporting Submission status Subcontracts Baseline Functionality: Subcontract detail Funding sources Amount information Subcontract closeout and correspondence Contacts Subrecipient monitoring (A-133) Invoice routing and approval

52. Release 3.0: July 08 - July 09 Functional Specification Determination August 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

53. Release 4.0: August 09- September 10 Functional Specification Determination October 10 – October 11 Development and QA Bio-Safety Management Enhancements: Submissions of MOU on biological materials, including select agents Submissions of MOU amendments and renewals Production of IBC minutes Monitoring of approved MOU Reporting of non-compliance Facilities inspection Export Controls / ITAR Management Enhancements: Certification questionnaire with routing approval Office of Foreign Asset Control (OFAC) purchases Chemical Tracking Enhancements: Controlled substance program

54. 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.

55. 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.

56. 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.

57. MSU Documentation And Assessment

58. 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.

59. 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.

60. 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.

61. 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.

62. 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.

63. 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.

64. 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.

65. 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.

66. 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.