UCLA's HR System
Business System Analysis
Opus is UCLA's new web-based HR system for faculty. The system replaces the previous paper process for performance reviews of academic employees. It also contains fielded faculty resume information and enables campus-wide reporting.
Opus is a technical system that automates complex business processes in a large-scale organization. The development issues that arise as a result of this complexity are analysed in a publication that I co-authored,
entitled "Who owns faculty data? Fairness and transparency in UCLA's new academic HR system."
The lean development team uses a blended agile and waterfall development approach. As a Senior Business Systems Analyst, I wear many hats with tasks including requirements elicitation, wireframing, creating functional and technical documentation, reporting design, coding a resume parser for a structured resume template, data model recommendations, and extensive data mapping.
Click below to see work samples.
To ensure a positive user experience, I engaged in open houses and user experience testing meetings with our user-base. Before a full-time User Experience Designer was hired, I developed Opus' wireframes using Balsamiq, with a mindset of the user's functional goals and usability best practices.
This wireframe below is for administrators who are assembling review committees and need to find reviewers based on area, expertise and rank, excluding those who are on leave and those with recent review committee service. This page appears when the user clicks advanced search options (next to the Search box) from the main committee assembly page.
Display Action Response Tables
A Display Action Response (DAR) Table is documentation used by developers to understand which parts of a webpage should behave in specific ways. More digestible than a long list of requirements, this visual version of requirements gives the authoring Business Analysts a systematic way to ensure requirements are captured.
I am certified in Seilevel "Visual Models", "Requirements Core Concepts" and "Elicitation Facilitation."
When users click here or there, what should happen? Examine the DAR table below to find out. This DAR Table explains the "Search For Review Committee (RC) Members by the Council on Academic Personnel (CAP) Case Specialist" page. The Advanced Search page wireframed above is the Advanced Search version of this simple search page.
+ Technical Diagrams
State Transition Diagram
By and large, the Academic History page requires the user to explicitly press Save to save any edits they have made to data. Exceptions are the cases of Delete and Verify, which if successful also cause a Save. Unsuccessful Saves, Deletes, and Verifications, as well as such triggers as session timeouts -- leave data in an unsaved state. These and a few other scenarios in which data would or would not be saved are detailed in the visual below.
Data Flow Diagram
Opus pulls in data from many campus systems to avoid duplicate data entry. So, when faculty need to make data corrections, the error resolution requests are routed to the original source system, improving data quality for the campus, not just for Opus. This visual model represents the "Book of Record" Data Flow.
PDF of Data Flow Diagram
This flow shows the actions available to the user, and at some level, what functionality needs to happen behind the scenes to facilitate the wanted system/UI behavior from the perspective of the user. This variant of a traditional user flow adds some technical detail in order to begin our team discussions about technical requirements. This snapshot in time of the flow shows some items in red - these items are questions to be asked or confirmed with the team.
+ Traceability Matrix
The following traceability matrix began as a business requirements document started by a teammate. I then added the "behavior" columns in order to clarify which workstream is responsible for executing each business requirement. The behavior columns act both as technical requirements and, also, they (in combination with the business requirements themselves) turned into test cases. This detailed format for technical requirements facilitates creation of development tasks for the upcoming development cycle, yielding more accurate time estimations.
PDF of Traceability Matrix (sample page)
+ Data Architecture
ETL Specification Template
I created an ETL (Extract, Transform and Load) Specification template in conjunction with the database architect and ETL developers.
I assist the principal database modeler in designing the logical and physical database models for our project. This includes
discussing design option tradeoffs and general validation based on knowledge of the business and data integration needs.
The model was created in Erwin, which I use at a novice-level. I also assisted with deployment and troubleshooting of the physical database in our four environments.
PDF of Logical Model for Release 1.1 Database
For Opus first beta release, I manually executed the ETL from source systems into Opus. For later releases, I provided ETL Specification documents to the then-hired ETL developer for dozens of source systems.
The ETL Specification information was compiled by conducting meetings with business and technical system owners, analysing technical documentation (data models, data dictionaries, data samples), directly accessing data in the source systems, and in some cases, synthesizing reports from consultants or team mates who met with owners and technicians of source systems. Though the graphics below were created by other team members, they provide a sense of the scale of data integration work undertaken by the Opus project. The first two images, of Internal and External data sources, represent the number of integrations planned as of 2013. The third image represents the set of system integrations planned as of mid-2014. As of early 2015, 40+ integrations are planned.