Enterprise Business System Software - PowerPoint PPT Presentation

Loading...

PPT – Enterprise Business System Software PowerPoint presentation | free to download - id: 6ef331-ZDEwY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Enterprise Business System Software

Description:

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

Number of Views:46
Avg rating:3.0/5.0
Slides: 67
Provided by: Megh73
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Enterprise Business System Software


1
  • Enterprise Business System Software
  • for
  • Research Administration
  • at
  • MSU

Peter D. Asquith Senior Advisor VPRGS
VPLCT Professor of Philosophy
2
The MSU Enterprise Business System Projects
(EBSP)
  • (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.

3
The Research Administration Component of EBSP
  • Given the importance of obtaining external
    funding to support the institutions 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

4
Overview of Current State of University Level MSU
Research Administration Systems
  • 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.
  • Dont contain standardized data element formats
  • Can simply be an EXCEL spreadsheet stored on an
    individual machine or a network drive.

5
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
6
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, FA 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
7
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
8
MSU Research Administration Software Strategy
  • 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 ones 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 MSUs 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.

9
The Research Administration Project Three
Components
  • 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.

10
  • Coeus
  • And
  • The Coeus Consortium

11
(No Transcript)
12
(No Transcript)
13
Coeus Two Different User Interfaces
  • 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.

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 PortalNeed 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 MembersBrown 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 MembersIndiana University Michigan
State UniversityThe Jackson Laboratory
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 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
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-award Post-award Compliance Technical
  • Lisa Oliva Renee Dolan Linda Triemer Ajay Patel
  • Stacy Salisbury Ann Spalding Kristen Burt
  • Teresa Thomas Craig ONeill Karalyn Burt
  • Peter Asquith Laura Baese
  • Basic members can participate in sub-committee
    deliberations, but have no vote.

32
Coeus Pros and Cons
  • ProsHistory 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.

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 Universitys
    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 ONeill, 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 ONeill, 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

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.)
  • Proposal Budget Development
  • Baseline Functionality
  • Proposal Development
  • Proposal Budget Development
  • Submitted Proposal
  • Proposal Routing
  • Grants.gov Integration

48
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

49
KRA Release 2.0 July 07- June 08 Functional
Specification DeterminationJuly 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 DeterminationJuly 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.0July 08 - July 09 Functional
Specification DeterminationAugust 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.0July 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

53
Release 4.0August 09- September 10 Functional
Specification DeterminationOctober 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
    MSUs current research
  • administration processes and determining MSUs
    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 MSUs
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 MSUs 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 MSUs
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.
About PowerShow.com