Advance Project

Phase 1
Scope Document

Background
At UCSF, the process through which a faculty member’s career develops from Appointment to Appraisal and then from
Assistant to Associate to Full Professor is called the appointment and advancement process. University of California
policy requires that faculty be reviewed and evaluated on a regular basis, usually every two to four years depending on
the series, rank and step.

The process requires the development of a packet of information (a checklist is used to ensure all required materials are
included in the packet) that enables various committees to review a candidate’s eligibility for appointment or advancement
or evaluate the candidate’s career thus far (Appraisal, Career Review, etc.). The packet progresses through various levels
of review and evaluation, which may include the Dean’s Office, the Office of the Vice Provost for Academic Affairs
(VPAA), and the Academic Senate’s Committee on Academic Personnel (CAP). Recommendations and evaluations are
received by the Vice Provost and a notification of approval is sent to the faculty member and corresponding Dean’s Office;
in the event of disapproval, the notification is only sent to the Dean’s Office. When the Dean’s Office informs the
department, the UCSF payroll system (PPS) is updated to reflect the personnel action. When the process is complete, the
entire packet is scanned to a PDF document that can be retrieved by Academic Affairs; redacted documents can be made
available to the faculty member upon request.

Although the process appears to be straight-forward, it can take more than a year from beginning to end. It is seen as
cumbersome and tracking of the packet through the various review points is difficult. It has been proposed that UCSF
build an electronic system to facilitate the process. This envisioned system is known as Advance.

Advance Overview
The Advance Project will deliver an electronic faculty advancement process in three phases. Phase 1 will consist of a
database called the Faculty Information System (FIS). Phase 2 will build functionality around FIS and include packet
development, routing and approval, as well as other functionality designed to facilitate the advancement process. Phase 3
will deliver an electronic solution to the final step in the advancement process: modifying faculty payroll information using
the Personnel Action Form (PAF).

This document is intended to clearly identify what is in scope and what is not in scope for Phase 1 of Advance.

FIS is envisioned as a central repository for faculty information on campus. As such, there are potentially a lot of data
elements that should be included in its design, but will not be considered for Phase 1. Phase 1 will include database
elements:
• directly related to faculty advancement – faculty profile data, advancement packet elements, elements
required to enable routing and approval, etc.,
• used by the Vice Provost’s Office to enhance its reporting capabilities related to faculty careers
Some of the user functionality related to packet development will not be delivered until Phase 2. Other elements that
might be considered essential to a complete repository of faculty information will need to be added at a later date, after a
more thorough analysis of a full-blown FIS can be performed.

Phase 1 will also deliver a variety of user tools to enable the users involved in the advancement process to see elements
of FIS that are related to their role in the process.
Advance Scope
Scope for Phase 1 includes
• A database to house data required for the advancement process.
• User interfaces (web pages) to display faculty profile information, as well as pages to enable Administrative users
to see the FIS data
• Security necessary to ensure that users only have access to the data they should have access to
• The ability to download the data displayed on the screen in to a csv or txt format
Scope for Phase 1 does not include
• Functionality related to CV generation
• Fields required solely for Phase 2, such as those related to the CV generator and those required for other aspects
of the advancement packet (internal/external reference text, teaching evaluations, routing destinations, approvals,
etc.)
• Routing processes including routing paths and approval hierarchies
• Work lists to help people manage their advancement process responsibilities
• Electronic signatures for approval processing
• Functionality to enable internal and external references to enter Advance to post reference text
• Interfaces to existing student evaluation systems
• Email notification from within Advance (links to the user’s email engine to assist the user in contacting people
related to the advancement process via email)

Users
Phase 1 will deliver some functionality to all users of the system. The majority of users will be able to log into Advance
and receive a view of data appropriate to their role. It is expected that Phase 2 will expand on this functionality, giving
users the ability to enter appropriate data related to their role in the advancement process.

The table below lists the users of Advance. Further details about their interaction with Advance follows the table.
Participant Responsibility and Actions
Faculty/Academic appointees • Review existing data specific to the faculty member
• Track progress of the packet through the process
Department users • Review list of academic appointees assigned to the department
Admin. Assistants and maintained in the Advance
HR Analysts • Track the progress of appointee packets
Chair
School users • Review list of academic appointees assigned to the school and
Admin. Analysts maintained in the Advance
Personnel Analysts • Filter the list by department
Deans • Track the progress of appointee packets
VPAA users • Review list of academic appointees maintained in the Advance
Admin Analysts • Filter the list by school and department
Director of Academic Pers. • Specialized reports to display advancement data
Vice Provost • Track the progress of appointee packets

Functionality that is in scope

Role and Row based security that will result in appropriate access to data:
• The role assigned to the user will determine what web pages the user has access to
• The user attributes (employee ID and Dept Code) will determine what data the user has access to.

C:\Documents and Settings\NHamilton.ITSEP\Desktop\Advance Project docs (subversion)\Documentation\Project Docs\Phase

1\Scope for Phase 1 v4.doc Page 2 of 9
Faculty will see a read-only view of:
• Payroll profile, including Name, Employee ID, Title, Primary Department, any Joint Department appointments, and
Salary Distribution similar to the data displayed in WebLinks
• Data elements entered into Advance (through a feeder system called miniFIS) by the Vice Provost’s office,
including Step, most recent advancement action, most recent advancement action date, next scheduled
advancement date
• Tracking data for any current action maintained in Advance, including Effective Date, Date received by VPAA,
Date Sent to CAP, Date received from CAP, perhaps a few other fields as identified in discussions with SMEs and
Working Group members

Department users will see a read-only view of:

• A list of Academic Personnel specific to that department and all “child” departments that are maintained in
Advance including Name, Employee ID, Title, Primary Department, any Joint Department appointments, most
recent advancement action, most recent advancement action date, next scheduled advancement date
• Tracking data for any current action maintained in Advance for individuals appearing on the Academic Personnel
list described above, including Effective Date, Date received by VPAA, Date Sent to CAP, Date received from
CAP, perhaps a few other fields as identified in discussions with SMEs and Working Group members

School users will see a read-only view of:

• What a Department user will see, but at the School level, plus:
• A filter by Primary Department will enable the school user to see a view exactly the same as the department user
to help them troubleshoot issues raised by the departments

Vice Provost for Academic Affairs users will have two types of view.
• What a School user will see, but at the campus level, plus:
• A campus-wide read-only view similar to what the schools and departments see; this view will include a filter by
school and by Primary Department to help them troubleshoot school issues

Functionality that is out of scope

There will be a number of Advancement process activities that will not be included as functionality in Phase 1. Some of
these activities will be included in the design of Advance Phase 2.
• When a faculty member sees a mistake in the data displayed in Advance, he/she will have to use standard
practices (email, phone call, etc.) to alert their departmental HR of the error
o Changes to data maintained in the payroll system can be made at the department level and will be
reflected in Advance a day after it is reflected in PPS
• When a department wants to accelerate or decelerate an action, that department chair will have to use standard
practices (email, interoffice memo, etc.) to alert the school administrators (and ultimately the VPAA user
responsible for maintaining Advance data through miniFIS) to make a change to the Advance data to reflect this
acceleration/deceleration decision
• When Advance data issues are discovered, email should be used to alert VPAA of the problem
• Workflow – the ability for the system to route information between and among different users to enable electronic
review and approval processing (this functionality is envisioned for Phase 2)
• Notification processes internal to Advance

C:\Documents and Settings\NHamilton.ITSEP\Desktop\Advance Project docs (subversion)\Documentation\Project Docs\Phase

1\Scope for Phase 1 v4.doc Page 3 of 9
Advance Phase 1 Requirements
Detailed requirements are based on the following process maps. The AS IS maps describe the entire advancement
process and have been reviewed and augmented by the functional owners (VPAA) and by the Steering Committee for
Academic Affairs Information Systems Initiatives (SCAAISI). The TO BE maps are specific to the functionality being
delivered in Phase 1 and include little of what would be considered the advancement process.

AS IS Process Maps
1.0 Departmental Processes: (the process begins with notification to the faculty member who starts the process)

C:\Documents and Settings\NHamilton.ITSEP\Desktop\Advance Project docs (subversion)\Documentation\Project Docs\Phase

1\Scope for Phase 1 v4.doc Page 4 of 9
2.0 Dean’s Office Processes: (this process begins when the Dean’s Office receives the packet from the department)

C:\Documents and Settings\NHamilton.ITSEP\Desktop\Advance Project docs (subversion)\Documentation\Project Docs\Phase

1\Scope for Phase 1 v4.doc Page 5 of 9
3.0 Academic Review Processes: (this process begins when VPAA receives the packet from the Dean’s Office)

C:\Documents and Settings\NHamilton.ITSEP\Desktop\Advance Project docs (subversion)\Documentation\Project Docs\Phase

1\Scope for Phase 1 v4.doc Page 6 of 9
4.0 Action Processes: (this process begins when the Dean’s Office receives the fully-reviewed packet)

The maps above describe the entire advancement process. Phase 1 is envisioned to provide limited functionality related
to the profile data for UCSF faculty and academic appointees. The TO BE maps below describe what will be delivered in
Phase 1.

C:\Documents and Settings\NHamilton.ITSEP\Desktop\Advance Project docs (subversion)\Documentation\Project Docs\Phase

1\Scope for Phase 1 v4.doc Page 7 of 9
TO BE Process Maps

1.0 View FIS Data

Requirements for development of a Faculty Information System:

1. FIS database
a. Data tables – must anticipate the Phase 2 requirements for significantly more fields/tables
i. Determine whether any campus systems will be used as building blocks for FIS (Folio, CHR, etc.)
b. Data
i. Identify all data elements required for Advance (Phase 1 and 2)
ii. Identify sources of existing data that will be used
1. PPS (or the Oracle tables fed nightly by PPS)
2. Mini-FIS (VPAA)
3. Other possible sources of existing data
a. Dean’s Office-maintained systems (PDB, Folio, etc.)?
b. Departmental systems (DOM, Pediatrics, LPPI, other large departments)?
iii. Identify specific data elements from existing systems that will be included in FIS
iv. Identify other data elements required by Advance (Phase 1 and 2) not held in other systems
v. Identify situations requiring one-time conversion of data
1. VPAA mini-FIS
vi. Identify situations requiring development of an interface
1. Define which data systems will feed FIS

C:\Documents and Settings\NHamilton.ITSEP\Desktop\Advance Project docs (subversion)\Documentation\Project Docs\Phase

1\Scope for Phase 1 v4.doc Page 8 of 9
 a. PPS/Oracle tables that hold PPS data
2. Security
a. Define roles based on business processes
i. The faculty member
ii. Department roles
iii. Dean’s Office roles
iv. VPAA roles
v. Other Central Administrative roles (Help Desk, Payroll, Audit, etc.)
b. Define what each role will see and incorporate into design of the user interface (web pages)
i. Define Use Cases
c. Identify users
d. Assign roles to users
3. User Interface
a. Define the data elements each role should see
b. Design and build view only pages
i. Include hyperlinks to resources like WebLinks, Academic Affairs (advancement checklists), etc.
c. Design any translation tables that will facilitate user understanding of the data
i. Title Code Æ Title (not the description displayed in PPS)
4. Reports and queries (aside from the display of data on the user interface (web) pages)
a. Eligibility report (business rules designed to display faculty eligible for advancement action based on data
maintained in FIS)
b. Advancement action activity reports to be determined
c. Define access to data for developing queries

C:\Documents and Settings\NHamilton.ITSEP\Desktop\Advance Project docs (subversion)\Documentation\Project Docs\Phase

1\Scope for Phase 1 v4.doc Page 9 of 9