1 / 29

Boston University Kuali Coeus Conference

Boston University Kuali Coeus Conference. Interfacing Kuali Coeus with a Financial System: Functional Design Perspective March 28 th , 2011. Agenda. Introductions Boston University Background Project Overview Functional Design Source of Truth Concept High-Level Requirements

kessie-garrett
Download Presentation

Boston University Kuali Coeus Conference

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Boston UniversityKualiCoeus Conference Interfacing KualiCoeus 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 KualiCoeus 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 KualiCoeus • 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 KualiCoeus 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 KualiCoeus • Electronic submission of grants.gov capable proposals • Additional interfaces with other backend systems including research compliance

  9. Functional Design – Source of Truth • KualiCoeus 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 KualiCoeus will be interfaced to SAP and to the Business Warehouse for reporting.

  10. Functional Design – Requirements • Considering our source of truth approach with SAP, KualiCoeus 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 KualiCoeus 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 KualiCoeus. We decided to enter cost-sharing information on the Commitments tab in the parent award document in KualiCoeus 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 • SapIntegrationServiceWeb 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: KCRM_Proj@bu.edu • Philip Infurna – pinfurna@huronconsultinggroup.com • Kathleen Foster – kfoster@bu.edu • Mohammed Kousheh – mkousheh@bu.edu

More Related