Boston University Kuali 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

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

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

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.

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

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)

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

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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

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

High-Level Technical Approach – Database Objects

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

High-Level Technical Approach - SapIntegrationService

High-Level Technical Approach – Interface Code Structure

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

Question and Answer

Contact Information General Project Contact: KCRM_Proj@bu.edu Philip Infurna – pinfurna@huronconsultinggroup.com Kathleen Foster – kfoster@bu.edu Mohammed Kousheh – mkousheh@bu.edu