Invested In Success

The Steering Council is populated by high level subject matter experts who have direct functional interests in the SIS Project. Critical decisions and recommendations on the SIS Project’s scope, structure, and budget will be answered by the Steering Council. 

 


Steering Council Decisions


Will credit cards be accepted for Fall 2016?

Student Financials
June 16, 2015


Decision: 

Yes, UCB will accept payment via credit card with a convenience fee for all charges assessed on the CS: Student Financial billing account.

Rationale:

Able to communicate that students and parents are provided a full selection of payment options to meet their needs and expectations.

How will admitted undergraduate applicants transition from Slate to Campus Solutions? What is the system of record for each step of the SIR process.

Admissions
April 16, 2015


Decision: 

Integrate Slate with CalCentral. SIR happens in CS via CalCentral.

Rationale:

Reduced risk of missing deliverable dates with existing team resources. Reduced time to develop solutions required for Graduate admissions.


For more information: Proposal Document

 

How to provide advising community with an 'Advising Toolkit'

Academic Advising
April 13, 2015


Decision: 

Create customized solution (bolt-on) for scheduling advising appointments, case management, forms, a student planning tool and workflow.


For more information: Proposal Document

Will CS delivered Direct Deposit functionality be used to replace the existing 'eftstudent.berkeley.edu' direct deposit system?

Student Financials
March 31, 2015


Decision: 

Student Financials met with business partner to discuss options. We agreed and decided that CS Direct Deposit functionality will not be used. The existing eftstudent.berkeley.edu direct deposit system will continue to be the EFT system for all students.

Rationale:

The delivered integration assumes that direct deposit data will be collected and maintained in CS. Currently, direct deposit data is collected and maintained by eftstudent.berkeley.edu. We cannot “replace” this system with CS, since it is also used for non-CS student refunds. (Today, over 13k non-CARS student refunds are issued annually by campus departments). Capturing direct deposit data in two systems (CS and eftstudent.berkeley.edu) may be confusing to students and does not support best practices.


Will the CS delivered 'Single Vendor ID' approach be used for processing CS student refunds?

Student Financials
March 30, 2015


Decision:

Student Financials met with business partner to discuss decision and it was decided that the single vendor ID approach will not be used.

The delivered integration utilizes a process where all student refunds are generated with generic vendor ID’s (one for direct deposit and one for checks).  Today, a unique vendor ID is automatically created in AP for each student when their student record is created. If we stopped this vendoring process for CS refunds, a need would still exist to create unique student vendor ID’s for non-CS refunds. Handling vendor ID’s one way for CS refunds and another way for non-CS refunds would be confusing and not support best practices.

Rationale:

Unique student vendor ID’s will still need to be created for campus departments reimbursing students for Non-CS refunds (i.e., travel and entertainment, etc.). Currently, over 13k vouchers are generated on an annual basis. The single vendor ID approach would cause undue hardship to campus departments and the AP vendor desk.

Next Steps: Student Financials will create functional specs for this process. Include regular address syncing requirement from CS to AP.


Pages