Meeting Minutes & Action Items Meeting Name UBC SASI

advertisement
Meeting Minutes & Action Items
Meeting
Name
UBC SASI Functional To-Be Process Validation for Access and Identity
Management (AIM)
Date
November 23, 2015
Time
1:00 to 2:30 PM
Location
Henry Angus 435
Attendees
Name
Parvin Bolourani
Title
Marianne Boyles
Change Management Specialist, SASI
Dr. Ian Cavers
Associate Dean, Senior Instructor Computer Science
Marcy Caouette (in lieu of
Stephania Burk)
Tarek Haji
Academic Student Coordinator, Arts
Dr. Paul Harrison
Associate Professor, Associate Dean Botany
Maggie Hartley
Director, Business Architecture, SASI
Marcela M. Hernandez
Director, Planning & Institutional Research (PAIR)
Carol Jaeger
Associate Dean, Academic Applied Science Faculty Electrical
and Computer Engineering
Jennifer Janicki (sp?)
Associate Director, Undergraduate Program Psychology
Department
Sandra Jarvis-Selinger
Associate Dean, Academic Pharmaceutical Sciences
Craig Kornak
Undergraduate Program Assistant, Microbiology and
Immunology
Jason Kwok
Acting Associate Director, Student Systems Management |
Enrolment Services
Salena Li
Undergraduate Coordinator, Physics and Astronomy
Pamela Lim
Assistant Dean and Director, Undergraduate Office, Sauder
School of Business
Jens Locher
Director, Strategic Business Projects, Faculty of Graduate &
Postdoctoral Studies
Nancy Low
Business Solutions Analyst, Enrolment Services
Debbie Mason
Business Analyst, SASI
William McKee
Assistant Professor, Director PRTC, Education and Counselling
Psychology, and Special Education (ECPS) Psychoeducation
Research & Training Centre
Donna Rota
Administrative Director Dean’s Office, MD Undergraduate
Project Administration, SASI
Page 1 of 7
Meeting Minutes & Action Items
Education, Faculty of Medicine
Christine Scaman
Associate Professor and Associate Dean, Academic, Land and
Food Systems
Marianne Schroeder
Associate Director – Teaching & Learning Technologies, Centre
for Teaching, Learning and Technology
Siriwan Sereewattana
Erin Shannon
Senior Programmer Analyst, Solutions Architecture, SASI
Associate Director, Enrolment Services
Janey Shum
Business Solutions Analyst, Enrolment Services
Renée Stephen (Computer
Science /Web App)
Web Applications Team Lead and Project Manager Computer
Science
Barbara Thirlwell
Change Management Specialist, SASI
Derek White
Manager, Learning Applications, Integrations and Analytics,
Centre for Teaching, Learning and Technology
Annie Yim
Associate Registrar and HR Director, Student Records &
Systems Management, Enrolment Services
Project Manager and Functional Lead, SASI
Asima Zahid
Agenda
•
•
•
•
•
•
•
Our AIM
Our Pain Points
Our Approach
Our Achievements
Our Work Progress
Our Future (Feedback/Concerns)
Our Guiding Principles (Group Activity)
#
Action Items
Raised by
1
Change management team to prepare
terminology documentation.
Marianne
Boyle
2
Review Guiding Principles feedback and
recommendations and respond
Erin
Shannon
Owner
Due Date
NOTES:
Our AIM:
 Create a framework to control access to the new SIS based on who a person is (e.g.,
admissions advisor) and what duties the employee performs.
 Refactor solution for Sauder and Grad to ensure that we have an holistic solution.
Our PainPoints:
 Paper Access Request Forms are confusing to fill in
Page 2 of 7
Meeting Minutes & Action Items
 Partial HR Knowledge – status at UBC unknown, no notice of changes/departures
 Manual Provisioning – manual steps to avoid duplicate accounts, access is additive
 Manual De-provisioning – access not removed
Feedback: General agreement and concerned that:
 Still using paper forms (as opposed to system to system talking)
 Lack of boundary understanding (how to assign)—relying heavily on the security
team to appoint
 People get used to seeing “everything”
 Not an automated process when people leave
 Mindful of what other universities do as well
Our Approach
Found we are unable to make sense of the SIS roles, and why people have the access they
have. Decision to:
 Look at other universities’ guiding priniciples
 Research case studies for controlling access. Best example: Pharmaceuticals / Siemens
case study where they did a business process review (BPR). Using this template, we
validated our processes (E.g. registering for a course, transferring credits) and identified
the people involved so that we could learn what the new SIS needs to do.
Our Achievements
 GRASP and Sauder are already operational.
 Campus Wide Login integrated with the new SIS so we know who is logging in. CWL
supports guiding principle that a person has one account.
 Controlled Access Behavior - use role groups to control what an employee, applicant
and/or student can see and do.
Feedback:
What does it (access behavior) mean?
 if you are an employee you see these areas of eVision, if you are student you see
that, if you are both you see both.
 if you are a TA you cannot change marks on a course you have taken.
Our Work Progress
 Smart Form (online) is an option but we must consider legal requirement to capture
signature of approver for requests, FIPPA.
 Actor Catalogue – identifies our people, our processes and what tasks they are doing
in the student lifecycle. Actor Catalogue is based on the discussions in workshops.
What are actors? Actors group people at a high level (e.g. the “Dean” actor category
includes Dean, Associate Dean, Assistant Dean, Dean’s delegate etc.).
Feedback: (Jennifer J)
 If you have multiple roles, you still get automated mail from student years.
A1: Design principles of SASI for learner management will need to handle how
student is contacted.
 Smart forms—still can’t fill them out after 20 years.
A2: Yes painpoint. If a form option is pursued we would engage subject matter
experts to understand the business needs, and use our UX team resources to create
a dynamic form that shows or hides content based responses from the person
completing the form.
Pain Point
Grad Students 8/31 (fluidity)—enrolling them 2 months earlier as a workaround
Page 3 of 7
Meeting Minutes & Action Items
Our Future:
Eliminate where possible manual and confusing processes to manage accounts
 Shell Accounts – pre-emptive strike to create (migrate) employee accounts. Shell
account = employee has account in new SIS but no permission to do anything. Can
use employee accounts in SIS to inform us who may need account in new SIS.
 Reports – use HR/SIS information (e.g. create reports to find out which employees
have left the university).
 Account Management - leverage employee details to automatically grant or disable
access (to fullest extent possible).
Feedback:
 Q1 (Paul Harrison) SITS no better than right now (SIS)?
o A1a: True. Opportunity exists to use roles to create accounts and grant access
in new SIS BUT the way we’ve done it for GRASP and SAUDER is the same as
before due to business decision at implementation based on strict timelines.
Recommend using information in our systems of record to inform account
management rules (E.g, HR is system of record for employee data). Faculty
Relations is well evolved. Faculty relations has looked at their HR data and
identified who their teaching and non-teaching instructors are, who their deans
are. We would like to set up a framework to use HR information to create
accounts and grant access for faculty type accounts.
o Followed by comment (Jens Locher ) Yes, there is opportunity to clean-up from
initial scope. Processes can be developed.
 Q2 (Donna Rota) Distributed medical program therefore members who are / need
CWL? (Jennifer) Access and Roles are not the same re: Hiring. Furthered by Ian,
there are employees who are not part of the university accessing.
A2: Yes CWL is required. CWL provides flexibility. Can allow access as guest -- a
person does not have to be an employee in HR.
Our 8 Guiding Principles
Discussion:
#3 probably had most response: Automate Provisioning and De-Provisioning access, where
possible
 Q1: (Ian) Is there a principle missing on “RIGHT ACCESS” e.g. business access /
granular approach versus # principle 3—provisioning and de-provisioning.
A1: granular roles are needed to control access to data, E.g., TA in English can only
see submit marks for English, to the course and section level.
Further comment still large piece of work to control the data (ties back to the
academic model). Who the people are; Where they are tied into; How the person fits
into the system. How do we automate at the “right level”; Managing roles “in-tandem”
already problematic.
 Q2: (Derek White) How do the principles address current processes (i.e. legacy)-efficient versus appropriate.
A: we looked at the business processes and ask is that process still appropriate. We
also look to the BAs as they discuss with stakeholders (i.e. the ones who might report
to you). This is what you told me. This is what we are thinking. Does this resonate?
 Q3: (Jens) Account management overhead needs to look at key elements: PEOPLE,
PROCESSES, DATA and ask what is available, how do we train people.
A: yes, limitation in lens. How they did it prior. Resources. BAs have the challenge
to take this on
 Q4: How is access controlled when request is made from downstream systems?
Page 4 of 7
Meeting Minutes & Action Items
A1: Policies on data sharing exist and will need to be reviewed with new lens.
Feedback stats:
Individual Post-its provided with the following input received-1: (11) 2: (9) 3: (18) 4: (11) 5: (5) 6: (8) 7: (7) 8: (7) *9: (8)
*Grey: What DOESN’T get officially captured, recorded.
Current is not sustainable—will attempt to move to a TO-BE Process
1. Ensure the right people, have the right access, to the right information, at the right time.
 Simplify forms for determining access levels.
 Possibility of read only access for some roles (E.g., faculty, program advisors)
 Provide more transparency
 Add flexibility to accommodate future roles (E.g. sessionals)
 Need to ensure that the ‘rigth information’ is informed by new academic model E.g.,
what is a learner and with sensitivity to downstream requirements for this data
 Need to consider system (application accessing SITS) as an actor
 How provisioned
 Security model
 Access model
 Too many people have access to send email to students. We have no principles to
govern this use of access
 How do you determine who should have access. Sicne based on the role in the
department you might need access to some things all the time or sometimes.
 Who gets to decide what Is the right access to the right people
 Systems accessing data – governance and access
 I think this is the only principle. The remaining points are actions plans that will bring
us to achieve our vision which is principle #1.
 Agree with (only principle) above.
2. Maintain a single identity for a person in the student information system
 I agree, the single identity is for UBC, not SISC
 Identities don’t belong inot the SIS. Identity should be meta –concept covering all
SoRs
 Don’t prejudge the possible combination of roles one individual might play
 What do you mean by single identity? A student who is hired as an employee who
will do jobs within SIS, how would this be able to be maintained as a single identity?
 When one has multiple roles which may have conflicting access, how do we resolve
the conflict?
 Non UBC staff accessing new system
 Not sure what maintain a single identity means
 Could be tricky for coop, peer advisors, or student/staff roles. Need to be able to
update quickly and remove access
 Can a student be excluded from acting on their own file when acting as a staff
member?
3. Automate provisioning and de-provisioning access, where possible
 Make provisioning more flexible (timing).
 Don’t require new users to know acronyms or the system
 Automatic notification if access hasn’t been used for a certain amount of time
 Didn’t encounter the word provisioning before today
Page 5 of 7
Meeting Minutes & Action Items














Fluidity/process to keep up as access requirements change (aside from
decommissioining i.e. student >faculty.
When can access be granted/revoked
Will HRMS support the new vision?
What would this automation be based on?
Important to have an approver for access, E.g., data governance.
Will there be a grace period, E.g., transition period , materity leave.
Levels of granularity of access to data. How do we automate these?
Access should be driven by effective date, not appointment
Maybe explicitly state a data governance principle as foundation for this
“Automatic Provisioning” should still include sign-off by appropriate authority
(downside of unintended errors too large)
Auto de-provisioning great when you know end date of a position.
How do systems using the data get updated/alerted?
This can only work IF HR and FR are processing appointments in a timely way
HR data is key but we need to think outside HR
4. Simplify end-user experience
 Need to define roles more clearly (i.e. application form for SISC access has become
too complicated, confusing)
 Simplify the form
 Expose role configuration to end user!
 What about confidentiality agreement and training
 Learn from current research on user experience
 Assumption – will this lead to a more efficient system
 Current for is complicated
 Confidentiality data security training online. Must pass course
 When replacing staff need to easily identify all the ‘roles’ they have (i.e., seriously
want to just copy last incumbent access)
 Pulling reports is complicated process. Sometimes needs ES help (E.g., if I can see
data for one student, I should be able to run report to get this information for many
student
 It’s a good goal. Could be that supervisors should be determing access level.
5. Reduce account management overhead
 Move as much as possible online (as noted).
 I don’t know what it means?
 Have it all online – no paper
 Note sure what account management overhead is?
 Agree with above (have it all online)
6. Be transparent and inclusive with partners
 Who are the partners?
 What do you mean by transparent? What do you mean by partners?
 Who are our partners? Within UBC? Outside UBC? Define.
 Not sure who partners are
 Define partners
 Non UBC staff in dual systems (UVIC & UBC)?
 Inclusive access to data or data definitions?
 Define inclusive and transparent?
Page 6 of 7
Meeting Minutes & Action Items
7. Adherence to FIPPA and information security policies
 Consider how to support provisioning of access to systems in ‘cloud’ or outside
Canada in appropriate ways, E.g., obfusicate data, tokenize
 Training for everyone to understand
 How do we handle security breaches?
 Agreed but tricky with start of course vs. start of appointment, E.g., connect access
this past year for TAs
 Online course with quiz
 Need to stress importance of what it means to have access to student data
 Instead of stopping ideas with the security privacy red flag. Focus on how we can
make things happen to be compliant
8. Monitor and review appropriate use and transaction of student data
 Any tracking of business transactions done in the system by CWL?
 Not clear what this means
 Sounds good, but also sounds difficult. Particularly important for multi-role individuals
student and staff
 What is the vision of this
 How do we audit what users have viewed appropriately
 Who?
 Yes we would like auditability.
9. General feedback
 Policy requirements/implications for access to student (SIS) data for other schools &
non-UBC employees
 Policy implications and requirements around HRMS hire dates and
authorization/timing into an SIS
 How do these principles address current processes i.e. appropriateness &
effectiveness.
 Processes and actions have impacts to final data outputs
 How do we manage an over proliferation of roles with “the right access”
 A faculty member’s ‘admin role’ (i.e. program advisor) is changed and no longer need
access to SIS, but his/her employment information in HR is unchanged. How would
AIM program address this kind of identity issue?
 What function and access levels the system has should be made transparent to
system users or potential users, specifically for users when they apply for access to
the system.
 How do the principles address requirements to address process alignment to new
academic model?
Page 7 of 7
Download