Who Owns Faculty Data?: Fairness and transparency in UCLA's new academic HR system

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                hsmall@it.ucla.edu    .     Chloe  Reynolds          creynolds@it.ucla.edu