Who Owns Faculty Data? Fairness & Transparency in UCLA’s New Academic HR System CHLOE REYNOLDS & HEATHER SMALL UCLA, IT SERVICES ICONFERENCE 3.26.15
Apr 15, 2017
Who Owns Faculty Data? Fairness & Transparency in
UCLA’s New Academic HR System
C H LO E R E Y N O L D S & H E AT H E R S M A L L
U C L A , I T S E R V I C E S
I CO N F E R E N C E
3 . 2 6 . 1 5
Topics
History of the project Issues a) Data Ownership b) Data Access/Privacy c) Data & Truth d) Data Representa@on
Q & A
Opus History Our Role ◦ Role – analysts on IT team building a new faculty informa@on system (Opus)
System Features ◦ Academic Personnel (AP) workflow, Curriculum Vitae data, Repor@ng
History ◦ Faculty have called for improvements to the AP review process since 1988.
◦ The AP process has been es@mated at $10M/year and takes up to 300 days.
◦ In 2010 a joint Academic Senate/Administra@on taskforce report, provided the impetus to build an electronic academic review system.
◦ Beta release in Dec. 2014; mul@ple major releases over the next year.
A. Data Ownership
Data Ownership Problem
◦ The value of the Opus data depends on a consistent set of expecta@ons about data fidelity, security, and access.
Mi@ga@on
◦ Iden@fy data stewards for each data element
◦ Display data steward informa@on to Opus users.
◦ Error correc@on begins with the authorita@ve source.
Data Ownership
But defining ownership is hard A tale of two salaries…
…And what about
publica@ons,
degrees,
community
service ac@vi@es?
Lesson # 1
In aggrega@ng data from various sources, you need to understand the story of the data in each context Who is “authoritative” is context-specific, rather than enterprise-‐specific
All of this needs to be factored in
for every single data element.
B. Data Access / Privacy
Access & Use Problem ◦ Balancing the business needs of the organiza@on, the public’s right
to know, and faculty privacy & security.
Mi@ga@on ◦ Granular visibility sedngs & transparency about usage
◦ Public visibility for minimal set of data
◦ Private visibility for data about works in progress ◦ Access to detailed data limited to those with a business need
◦ Review process for reques@ng data for new uses
PrioriCzing access & use
…when does faculty privacy trump the public’s right to
know?
…when does business need trump faculty privacy?
What does the public have the right to
know?
Access & Use
Lesson #2
Fear of change occurs at every level of projects and organizations
Pudng things ‘under the microscope’ and scrutinizing practices and data can create a sense of exposure and vulnerability. Stakeholders often have overlapping and/or competing interests and incentives around how data are collected, used, and interpreted (Borgman, 2013).
C. Data & Truth
Case Reviewer
Candidate
Researcher
Chair, Dean or other Administrator
Committee Member
Opus will be used by people in several different roles
External Reviewers Staff Public
Data Sources Data will come from many sources ◦ Internal (campus) systems ◦ External systems ◦ Data entry
For example ◦ From the student registrar system: course level, course @tle, number of instructors, term, enrollment
MulCple NarraCves Problem: Mul@ple narra@ves ◦ Data elements comes in from different sources ◦ Updated and augmented by different par@es ◦ Viewed by various user groups ◦ Viewed for different purposes than they were collected for
Mi@ga@on: Transparency, Annota@ons, Educa@on ◦ Data provenance transparency, annota@ons, data literacy educa@on
Example ◦ Enrollment: as indicator of level of faculty work, as a financial metric, as a measure of student body size
RepresenCng MulCple Truths: AnnotaCons and DescripCons
RepresenCng MulCple Truths: AnnotaCons and DescripCons
D. Data RepresentaCon
RepresentaCon Issues Problem: Reducing Informa@on to Data points ◦ Workload reduced to course size, student evalua@on ra@ngs, number of publica@ons, amount of grant money, etc.
Mi@ga@on: How to represent mul@ple truths ◦ Annota@on and descrip@ons ◦ Data literacy educa@on Examples ◦ Enrollment -‐ co-‐teaching/seniority, cross-‐lis@ng, exchange & extension students, theater ◦ Publica@ons -‐ publica@on pakern variance by discipline, early-‐cited ar@cles emphasis, etc.
◦ Gray lines disadvantage the modest, but seem “fair”
RepresentaCon Issues Categories ◦ Publica@on Types ◦ Obituaries, Interviews (about me, by me, or of me)
◦ Degree Types ◦ translate?, when to merge, maintenance, crosswalks
Terminology ◦ Awards, etc.
Lesson # 3 SemanCcs maRer
Seman@cs are @ed to iden@ty and cultural associa@on Who decides what things are called? How do you come to a compromise when stakeholders disagree?
Overarching Lessons Learned
Lesson # 4 Data projects can expose & exacerbate
…policy gaps, inconsistencies in prac@ce, long-‐standing disagreements, old habits.
One of the main reasons this project was ini@ated was because campus iden@fied the AP process to be in need of re-‐engineering. We were akemp@ng to resolve transac@onal inefficiencies, but those proved to be a symptom of larger, more complex issues.
“Can’t you just go build the system?”
Why do technologists find themselves wrangling with what are essen@ally policy/legal/ideological issues? It’s incumbent on the technical team to educate stakeholders about the complexity.
Q & A Live System h"ps://opus.ucla.edu
Opus FAQ h"ps://opus.ucla.edu/public/FAQ.shtml
Opus Privacy h"ps://opus.ucla.edu/public/privacy.shtml
Original Charge h"ps://www.apo.ucla.edu/ini<a<ves/opus/charge
Heather Small [email protected] . Chloe Reynolds [email protected]