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


What bio/demo data can be updated programmatically?

Campus Community
March 12, 2015


Decision:
In general, only biographical/demographic contact information (address, phone, and email) should be updated programmatically in Campus Solutions (CS).  Since CS will be the system of record for student bio/demo data, allowing other systems to update that data via batch processing would have the potential to cause significant data integrity issues.

There will be some exceptions to this rule, to allow for situations where more recent, verified data is available to load.  In most cases, we anticipate that requests for exceptions will be reviewed and decided on by the project's functional and technical team leads (who meet weekly to discuss cross-module issues), with business partner consultation as needed.  If the leads are unable to reach consensus on an issue, we will refer it to project management and the Steering Council.

The currently agreed-on situations involving programmatic updates to bio/demo data (other than contact information) are:

  • If Berkeley decides to integrate CS and our Human Capital Management (HCM) system, message-based syncing of some bio/demo data elements will occur:  Names, Gender, Social Security Number, Date of Birth, Date of Death, and Marital Status.  Two contact information data elements, Addresses and Phones, will also be synced.
  • Financial Aid's Institutional Student Information Record (ISIR) process will be able to insert and update verified Social Security Numbers.  We have requested a database-level audit trail for this field in CS, so that we can track changes.

Rationale:
Campus Solutions will be the system of record for student bio/demo data.


How and when to roll-out requisite functionality to have least negative impact on the UCB culture.

Student Records
February 20, 2015


Decision:
Fall 2016:
Requisites that are currently enforced will be configured and enforced in CS Enrollment for continuing students who begin enrolling for fall 2016 in April 2016.   This includes course restrictions (majors, level, etc.) as well as those few courses that are enforcing course pre-requisites post enrollment if those departments are comfortable enforcing requites at the time of enrollment.

Spring 2017:
Full-blown CS requisite functionality as part of the spring 2017 roll-out, enrollment begins in fall 2016.

The SR Team will work with Academic Advising and academic units to determine:

  1. Specific courses that will have requisites enforced; and
  2. Real requisites that should be enforced, as opposed to recommended preparation. 

Assumptions:

  1. Transfer credit articulation for transfer students will be processed prior to CalSO.
  2. PERC (Post Enrollment Requisite Checking) functionality will be utilized at the end of fall 2016 to identify students who did not successfully complete a requisite that was conditionally satisfied at the time of enrollment.

Rationale:
This decision allows UC Berkeley to maintain the current level of course restriction while giving the campus adequate time to manage the cultural shift that enforcement of requisites will bring.  It provides the added benefit of giving the end-users a period of time to adjust to and gain confidence in the new system.


12 Unit Repetition Limit Strategy

Student Records
February 19, 2015


Decision:
Keep current manual after the fact report + manual coding business process.  Repeat codes will be applied to course(s) that exceed the 12 repeat units and a report would be generated for Records. No GPA will be calculated for the student until after appropriate steps are taken to code and store the students information (including courses, grades, grade points, etc) so that a correct GPA can be calculated.

Rationale:

  1. First, we are assuming no change in Berkeley Academic Senate Regulations.
  2. We have been advised that Campus Solutions (CS) cannot automatically process Berkeley's policy. In particular, CS cannot automatically calculate the GPA according to Berkeley Senate policy.

We have also been advised that staff can query CS to determine when a student has repeated 12 or more units. In addition, we have been advised that CS will enable staff to identify the student and to appropriately count units attempted and grade points awarded in a manner consistent with campus policy. 


Which catalog year will be used to set up undergraduate requirements in SIS

Academic Advising
January 28, 2015


Decision:
Undergraduate requirements will be built starting with the 2012-2013 catalog year.

Rationale:
88% of students could graduate within 5 yrs with an accurate degree audit.

Advisors can access more complete advising information.

No need for parallel DARS and SIS sytems. DARS maintenance can be discontinued and advisor only access one system.


When will the Degree Audit functionality Go Live?

Academic Advising
January 28, 2015


Decision:
Degree Audit functionality will go live in Sept 2016 for the Spring 2017 term. Other Academic Advisement components go live at a date still to be decided.

Rationale:
The smaller spring term population will reduce the impact on advisors.

Degree audit is dependent on catalog work scheduled for July 2015.  A 12+ month configuration effort is required to ensure comprehensive and robust audit functionality.


Pages