Boston UniversityKuali Coeus Conference

Interfacing Kuali Coeus with a Financial System: Functional Design Perspective

March 28th, 2011

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

2

Introductions

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

3

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

4

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.

5

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

6

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)

7

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 grants.gov capable proposals• Additional interfaces with other backend systems including

research compliance

8

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.

9

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

10

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.

11

Functional Design – Use of Hierarchy

• Because our system will interface with SAP’s Grants Management module, our hierarchy needs to match theirs.

12

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.

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.

13

KC SAP

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.

14

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.

15

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.

16

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.

17

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:

18

Allows a user to indicate which nodes in the hierarchy should be interfaced.

Allows a user to validate awards for transmission.

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:

19

This information is displayed according to SAP’s format.

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

20

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

21

High-Level Technical Approach - Business Objects

• New Business Objects added to Spring and OBJ– AwardExtension– SAPTransmission

22

High-Level Technical Approach – Database Objects

23

High-Level Technical Approach – Web Service

• SapIntegrationService– Perform Validation– Execute Transmission of Data to SAP

24

High-Level Technical Approach - SapIntegrationService

25

High-Level Technical Approach – Interface Code Structure

26

High-Level Technical Approach – Core KC Code Changes

• Minimal changes to KC core code

27

Question and Answer

28

Contact Information

General Project Contact: KCRM_Proj@bu.edu

• Philip Infurna – pinfurna@huronconsultinggroup.com • Kathleen Foster – kfoster@bu.edu • Mohammed Kousheh – mkousheh@bu.edu

29