Presentation on theme: "Boston University Kuali Coeus Conference"— Presentation transcript:
1Boston University Kuali Coeus Conference Interfacing Kuali Coeus with a Financial System: Functional Design PerspectiveMarch 28th, 2011
2Agenda Introductions Boston University Background Project Overview Functional DesignSource of Truth ConceptHigh-Level RequirementsWorkflow ComponentsCustomizationsHigh-Level Technical ApproachQuestion and AnswerContact Information
4Boston University – General Information Large private university in the City of BostonTwo Campuses: Medical and Charles River17 schools and collegesResearch Program (FY2010)1,786 awards, totaling $425,439,868Broad funding portfolio: NIH, NSF, Ed, DOD, private foundations, NASA, DOE, industryNational Emerging Infectious Disease Lab (NEIDL) -- BSL-4 lab
5Research 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.
6Project Overview Two Phased implementation of Kuali Coeus Phase 1: Proposal Log, Institutional Proposal, AwardsPhase 2: Proposal and Budget DevelopmentPart of a larger initiative to replace and modernize University systems and processes including the implementation of SAPPhase 1 go-live of Kuali Coeus coincides with the Phase 1 go-live of SAP on July 1st of 2011Phase 2 will begin immediately following the completion of the first phase and is targeted for completion on July 1st of 2012
7Project 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 proposalsImplementing data feeds to populate and maintain enterprise data (People, Departments/Units)Implementing a new reporting systemInterfacing with the new financial system (SAP)
8Project 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 administrationInternal routing and approval of ALL research applications through Kuali CoeusElectronic submission of grants.gov capable proposalsAdditional interfaces with other backend systems including research compliance
9Functional 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.
10Functional Design – Requirements Considering our source of truth approach with SAP, Kuali Coeus will be responsible for the following data:Sponsors and SubcontractorsAward “Master Data” (All identifying information about an award (Title, Sponsor, Principal Investigator, etc.)Award BudgetsTherefore, the interface will handle the following transactions:Award CreationAward ModificationsAward CloseoutNew Sponsors/SubcontractorsChanges to Sponsors/Subcontractors
11Functional Design – Approach Business owners selected delegates for our design team – members of OSP and PAFO were includedDesign team met twice each week for two hour sessions from September to NovemberWe 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.
12Functional 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.
13Functional 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.KCSAP
14Functional 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.
15Functional 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.
16Functional 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.
17Functional 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.
18Functional 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.
19Functional 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.
20Functional 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).
21High-Level Technical Approach Customization (doesn’t require re-create and redeployment)Code Table ChangeAward Data ConversionNew 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 SAPNew Transmit to SAP panelCustom Web ServiceSapIntegrationService Web Service
22High-Level Technical Approach - Business Objects New Business Objects added to Spring and OBJAwardExtensionSAPTransmission