Presentation is loading. Please wait.

Presentation is loading. Please wait.

Boston University Kuali Coeus Conference

Similar presentations

Presentation on theme: "Boston University Kuali Coeus Conference"— Presentation transcript:

1 Boston University Kuali Coeus Conference
Interfacing Kuali Coeus with a Financial System: Functional Design Perspective March 28th, 2011

2 Agenda Introductions Boston University Background Project Overview
Functional Design Source of Truth Concept High-Level Requirements Workflow Components Customizations High-Level Technical Approach Question and Answer Contact Information

3 Introductions Philip Infurna – Project Manager (Huron Consulting Group) Kathleen Foster – Functional Lead Mohammed Kousheh – Technical Lead

4 Boston University – General Information
Large private university in the City of Boston Two Campuses: Medical and Charles River 17 schools and colleges Research Program (FY2010) 1,786 awards, totaling $425,439,868 Broad funding portfolio: NIH, NSF, Ed, DOD, private foundations, NASA, DOE, industry National Emerging Infectious Disease Lab (NEIDL) -- BSL-4 lab

5 Research Administration at Boston University
Historically, the university has maintained an Office of Sponsored Programs on each campus; the two offices evolved separately over time, with separate leadership and separate procedures. The implementation of Kuali Coeus is one part of a larger initiative to standardize research administration policies and procedures across the two campuses. OSP handles all pre-award functions and some post-award (non-financial) functions. A single Post-Award Financial Operations (PAFO) office handles all post-award financial transactions.

6 Project Overview Two Phased implementation of Kuali Coeus
Phase 1: Proposal Log, Institutional Proposal, Awards Phase 2: Proposal and Budget Development Part of a larger initiative to replace and modernize University systems and processes including the implementation of SAP Phase 1 go-live of Kuali Coeus coincides with the Phase 1 go-live of SAP on July 1st of 2011 Phase 2 will begin immediately following the completion of the first phase and is targeted for completion on July 1st of 2012

7 Project Overview – Phase 1 Objectives/Scope
Create the foundation for phase 2 by replacing and enhancing the back-office / central administration tools. This includes: Standardizing both the systems and processes of two separate campuses (Medical Center, and Main Campus) Replacing two legacy systems (one for each campus) Converting Data for all existing awards and pending proposals Implementing data feeds to populate and maintain enterprise data (People, Departments/Units) Implementing a new reporting system Interfacing with the new financial system (SAP)

8 Project Overview – Phase 2 Objectives/Scope
Improve customer service to the BU research community through the standardization of internal workflows and approval processes and new modern tools for research administration Internal routing and approval of ALL research applications through Kuali Coeus Electronic submission of capable proposals Additional interfaces with other backend systems including research compliance

9 Functional Design – Source of Truth
Kuali Coeus will be the “Source of Truth,” or system of record, for all non-financial (i.e., non-expenditure) sponsored research information, including award budgets. Award Data entered into Kuali Coeus will be interfaced to SAP and to the Business Warehouse for reporting.

10 Functional Design – Requirements
Considering our source of truth approach with SAP, Kuali Coeus will be responsible for the following data: Sponsors and Subcontractors Award “Master Data” (All identifying information about an award (Title, Sponsor, Principal Investigator, etc.) Award Budgets Therefore, the interface will handle the following transactions: Award Creation Award Modifications Award Closeout New Sponsors/Subcontractors Changes to Sponsors/Subcontractors

11 Functional Design – Approach
Business owners selected delegates for our design team – members of OSP and PAFO were included Design team met twice each week for two hour sessions from September to November We discussed a variety of business scenarios and decided how to configure the system for our needs. We also needed to think about how our decisions would affect reporting. Documented our design in a series of Process Design Documents (PDDs) PDDs were reviewed and approved by business owners and project sponsors.

12 Functional Design – Use of Hierarchy
Because our system will interface with SAP’s Grants Management module, our hierarchy needs to match theirs. The parent award contains master data about the award as a whole. The child award(s) represent accounts in the financial system. Each award has at least one child; more complex awards might have many children. All funds are distributed to the child level. Award budgets are maintained at the child level.

13 Functional Design – Use of Hierarchy
Even when an award hierarchy is more complex, all funds are distributed down to the lowest level, and award budgets are maintained at the lowest level. KC SAP

14 Functional Design – Use of Hierarchy
We ran into some complications when trying to match our Kuali Coeus hierarchy to the planned SAP GM hierarchy. Two examples: Different Award Numbers in KC and SAP: KC and SAP have two different numbering conventions. We decided to use the account number field on the Parent Award to capture the SAP Grant Number and the account number field on the child award(s) to capture the SAP Sponsored Program Number(s). Cost Sharing: The SAP GM design called for a separate sponsored program for cost-sharing. We didn’t want to create a separate child for cost-sharing in Kuali Coeus. We decided to enter cost-sharing information on the Commitments tab in the parent award document in Kuali Coeus and have our interface create a new sponsored program when we send the record to SAP. The interface we designed has to navigate the above issues, and many others.

15 Functional Design – Use of Terms
We configured many of our Award terms to map to certain values in SAP, so the selection of particular terms (foreign travel not allowed, for example), results in the shut-off of certain budget categories in SAP. We added a new term type, called “Special Award Restrictions,” to handle any terms that didn’t seem to fit in the delivered term types.

16 Functional Design – Workflow
At BU, the award set-up process is initiated by OSP and completed by PAFO. Although the Award documents, the Time and Money document, and the Award Budget document can each have their own workflow, we decided to route only the Parent award document.

17 Functional Design – Workflow
We will create a “group” in KC for PAFO staff. Only the members of this group will have permission to transmit award data to SAP. PAFO staff will be able to access awards for review by using the Action Items List.

18 Functional Design – Customizations
The interface between KC and SAP was entirely custom built by rSmart. They created new a Transmit to SAP panel on the award actions tab: Allows a user to indicate which nodes in the hierarchy should be interfaced. Allows a user to validate awards for transmission.

19 Functional Design – Customizations
Clicking on one of the awards that passed validation allows a user to preview the information that will be sent to SAP: This information is displayed according to SAP’s format.

20 Functional Design – Customizations
Other enhancements include the Child Type and Child Description fields. Child Description displays as part of the award hierarchy whenever it appears. This allows easy sight recognition of the children, particularly in more complex hierarchies. Child Type maps to certain values in SAP (for example, Fabricated Equipment).

21 High-Level Technical Approach
Customization (doesn’t require re-create and redeployment) Code Table Change Award Data Conversion New Database Tables for the added fields and history of transmitted awards. Enhancement (requires re-create and redeployment) KNS extended Attribute feature to add new fields needed for SAP New Transmit to SAP panel Custom Web Service SapIntegrationService Web Service

22 High-Level Technical Approach - Business Objects
New Business Objects added to Spring and OBJ AwardExtension SAPTransmission

23 High-Level Technical Approach – Database Objects

24 High-Level Technical Approach – Web Service
SapIntegrationService Perform Validation Execute Transmission of Data to SAP

25 High-Level Technical Approach - SapIntegrationService

26 High-Level Technical Approach – Interface Code Structure

27 High-Level Technical Approach – Core KC Code Changes
Minimal changes to KC core code

28 Question and Answer

29 Contact Information General Project Contact: Philip Infurna – Kathleen Foster – Mohammed Kousheh –

Download ppt "Boston University Kuali Coeus Conference"

Similar presentations

Ads by Google