CHRS Glossary
This is an index of acronyms and terminology that are essential to the CHRS program
Term |
Definition |
---|---|
AM |
Absence Management |
AVP |
Academic Vice President |
BA/BB |
Benefits Administration / Base Benefits |
BI / DW |
Business Intelligence - Data Warehouse |
BPF |
Business Process Flow is a visual depiction of the future standard CHRS business process. Its purpose is to accurately depict the standard CHRS process for accurate communication of that standard process to all parties; and to enable everyone to speak the same language. This is a living document that gets updated throughout the Design and Build phases of CHRS |
BPF Step |
is a shape on the business process flow depicting a step in the overall process. BPF Steps are assigned a unique number on a single BPF, typically 1.1, 1.2 etc. An optional BPF Step is a step that may not be applicable at every campus AND there are no negative impacts if that step is not run at a campus |
BPG |
Business Process Guide is a step by step guide on how to execute the business process in CHRS. This is a living document that gets updated throughout the Design and Build phases of CHRS |
CABO |
Chief Administrators and Business Officers |
CFO |
Chief Financial Officer |
CHRS |
Common Human Resources System |
CIO |
Chief Information Officer |
CMCT |
Change Management and Communications Team |
CMS |
Common Management System Team |
GRP |
Gap Resolution Form is the form that identifies the proposed solution to resolve an identified Gap. The form also vets the proposed solution against CHRS guiding principles. To be completed for every gap or group of gaps identified during Solution Design Activities. |
HECH |
Higher Education Constituent Hub |
HRO |
Human Resources Officer |
IPP |
Integrated Program Plan |
ITAC |
Information Technology Advisory Committee |
LCD |
Labor Cost Distribution |
PDM |
Profile Data Mart is the tool that will help human resources to identify data standards |
PUM |
PeopleSoft Upgrade Manager |
RS |
Recruiting Solutions |
SCI |
Sierra-Cedar consultants provide project management in cooperative unity with the CHRS Program Team |
SDW |
Solution Design Workshop |
SLA |
Service Level Agreement |
SME |
Subject Matter Expert |
TAE |
Temporary Academic Employment |
TF |
Temporary Faculty |
TUG |
Technology Users Group |
UPK |
PeopleSoft User Productivity Kit |
WA |
Workforce Administration |
WBS |
Work Breakdown Structure |
9.2 Vanilla |
refers to the PeopleSoft 9.2 that does not include software modifications |
9.2 Configuration |
refers to the ability to make changes to PeopleSoft 9.2 using configurable capabilities within the software to address gaps without having to perform software modifications |
Application Security |
is the use of software, hardware, and procedural methods to protect applications from external threats. Once an afterthought in software design, security is becoming an increasingly important concern during development |
Baseline Modifications |
This represents previous modifications the CMS Team has made to PeopleSoft 9.0 |
Business Process |
is a systemwide view, as opposed to a campus-by-campus view, of looking at the business processes using PeopleSoft 9.2 |
Business Process Standardization |
is the process of identifying key HR business processes and by reviewing the business process flow (BPF) ensuring the system and other tools are used in a consistent way across all campuses. Adherence to CHRS Guiding Principles is key. |
California State University (CSU) |
Refers to the system comprised of 23 campuses and the Office of the Chancellor. |
Campus Acceptance Testing |
is the last phase of the software testing process, that involves campus end-users. During Campus Acceptance Testing, actual campus software users test the software to make sure it can handle required tasks in real-world scenarios, according to specifications |
Change Advisory Committee |
advises the CHRS program on campus preparation and readiness, communications, training as well as the overall change management strategy. The focus of the change advisory meeting is to advise the CHRS Program team on change management related activities related to campus preparation and readiness, communications, training as well as the overall change management strategy. The Change Advisory group meets monthly via Zoom |
Campus Change Teams |
are teams that help support the CHRS changes locally at each campus. The focus of the campus change teams is to build a network to support the CHRS Program and is focused on information sharing, collaboration and tools to help support change management at each campus. The Campus Change teams meet monthly via Zoom. It is recommended that the campus change team include one or more persons (varies by campus) who are able to share communications across divisions (divisions include Faculty Affairs, HR, Student and Finance –as the key groups/divisions to receive communications) |
Campus Configuration |
has to do with all the standard values in the software - job codes, benefits plans, reporting of time - that are configured centrally |
Campus Mapping |
is a method that is employed as part of a campus data clean up. If a campus decides to not clean up their data prior to standardization, a campus mapping tool must then be put in place to help in this process. |
Campus Solutions |
Campus Solutions is the name of the Oracle student application. The application previously was called Student Administration (SA). |
Campus-Specific |
is an interface that is not standardized and is developed and maintained by the campus, using CMS-defined standards, and undergoing CMS review prior to activation in CHRS. |
Change Management |
is a structured process, based on social science research, for managing the people side of a program and includes processes, tools and techniques to facilitate the adoption and use of a new way of doing work. For the CHRS Program and any large program, effective change management is critical in this process, and requires engagement across a broad audience within the CSU |
Change Network |
will play an important role in the design, development, and implementation of the CHRS program. The primary objectives of the Systemwide Change Network are to: 1) Gather input and feedback regarding the CHRS program and related work activity; 2) Analyze and assess business readiness for the changes resulting from the new system;3) Help each campus adjust to and effectively implement the changes in the new system; and, 4) Facilitate communications to all impacted stakeholders across divisions including Faculty Affairs, HR, Student and Finance |
CHRS Deliverables |
is the functional prototype of the new HR solution by module. |
CHRS Integration |
interfaces between CHRS and other systems (i.e., PIMS, benefit providers) |
CHRS Solution Design |
is the design of the common CSU Human Resources application built on a single database platform with standardized business processes and standardized data elements |
CMS Central |
The support team comprised of members from CMS application and technical teams, based at the CO. CMS Central supports the functional and technical operations of the CHRS baseline. |
Common Door |
is developed by CMS. These deliver an exact structure and format for every field that comprises the interface; for example, a date field cannot deviate from 00/00/0000 to 0000/00/00 at another campus. Each campus must extract and convert their data into the exact format required for upload into CHRS. |
Common Financial System (CFS) |
The delivered Finance baseline that combines data from all 23 campuses and the Office of the Chancellor in a single production database instance. The project name for the work required to combine data from the 23 campuses and the CO into a single Finance database. |
Common Human Resources System (CHRS) |
The delivered HR Baseline that combines data from all 23 campuses and the Office of the Chancellor in a single production database instance. The project name for the work required to combine data from the 23 campuses and the CO into a single HR database instance. |
Common Management System (CMS) |
The CSU systemwide common information systems environment that enhances the collective operation of administrative functions in a sustainable and cost-effective environment. |
Common Solution |
Is developed by CMS and used by all campuses as delivered. All exceptions must be submitted and reviewed by the program team on a case-by-base basis. |
Conversion |
is the process of migrating data from campus Human to the Common Human Resources System (CHRS) |
Conversion Testing |
verifies that one data format can be converted into another data format so that the converted data format can be used seamlessly by the application under test appropriately |
CS 9.2 Split |
is the pre-requisite project to CHRS. The CS 9.2 Split splits campus Human Resources and Campus Solutions |
Data Cleanup |
is part of the HR Data Standardization project, with the objective to ensure that standardized data values are being consistently and uniformly applied in the CHRS system. Data fields are identified in the Design phase, the usage is standardized (i.e., limit the number of characters, specify only certain fields via drop-down menu), and finally, reach into the system itself, extract the targeted data and update it to match the new guidelines. Cleanup may be a combined effort between CMS and the campuses |
Data Governance |
is a cross-functional governance body that will represent all of the appropriate constituencies that can validate that there will not be unintended consequences when changes occur. This team will provide support to the day-to-day support needs of diverse business applications (human resources, student services, finance and budget) and business requirements |
Data Masking Initiative |
is a service provided by CMS in partnership with Unisys. The technology provides data security by replacing sensitive information with a fictitious equivalent that can be used for development, testing, and analytics without risk of exposing the original data |
Data Retention |
are guidelines for how long to retain non-paper data in the system, what to retain, how it should be secured, and which group of employees are impacted |
Data Standardization |
is the process by which all campuses, including the Chancellor's Office, will use the same common fields of employee-level data (example: Gender). This process is directly linked to Governance. CALPERS helps to define the common definitions by which common fields are arrived at |
Decision Reached |
when workshop attendees have reached an agreement/made up their mind about a topic or item |
Decisions Pending |
when workshop attendees have identified an item that needs to be discussed and decided by either CHRS Governance or a different group |
Design Spec |
or Design Specification is a detailed document explaining how a design is made, what it is intended to do, and how far it complies with the requirements. It provides information about the characteristics of a project or product to set criteria that the developers will need to meet |
Enterprise Reporting and Data Warehouse Services |
Team responsible for the development and delivery of the CHRS HR data warehouse and analytic reports. |
Faculty Administration |
Refers to the group of requirements and/or delivered functionality unique to faculty. Includes administrative functions such as tenure and tenure promotion, WTU accumulation, stipends, etc. |
Faculty Taskforce |
|
Faculty Workgroup |
|
Frequently Asked Questions (FAQ) |
Communication tool used to collect campus questions and post answers to questions with common themes. |
Functional Specs |
or Functional Specifications are the documentation of functional requirements |
Gap |
is functionality that is required for the Common HR Solution (CHRS) (CSU-wide). The functionality in question currently does not exist in the CSU Baseline. |
Governance |
is the framework of rules and practices by which the governing board ensures accountability, fairness, and transparency in the CHRS program's relationship with all its stakeholders |
Higher Education Constituency Hub (HECH) |
Tool selected to manage integration between the HR and CS databases. |
Human Resources:
A. Systemwide HR B. HR Application C. HR Baseline |
A. Systemwide HR is a department based at the Chancellors Office that establishes and governs systemwide HR policies.
B. Oracle Human Resources application (as delivered).
C. The HR Baseline contains the final product delivered to campuses, which includes both Oracle-delivered functionality and custom modifications. It commonly refers to the product delivered prior to the CHRS project, which is implemented in 24 production databases (one for each campus and the CO). When the CHRS project is complete, the HR Baseline will simply be called CHRS. |
Integration |
refers to any read / write data (any data that is read or written) from the standpoint between CHRS and any external system |
Interfaces |
are programs that either read or write data either from or to CHRS |
Issues |
are items to be reviewed and assessed BEFORE the team proceeds |
Iterative Development |
is a way of breaking down the software development of a large application into smaller chunks. In iterative development, feature code is designed, developed and tested in repeated cycles |
Mod Specs |
or Modification Specifications are documentation of the technical details of a modification |
Module |
in PeopleSoft represents a bundle of forms, tables and processes associated to a specific HR function that can be accessed via PeopleSoft. For example: Absence Management Module |
Module Lead |
is the position that provides expertise on CSU systemwide Policy, Regulations, Practices, CBAs. Responsibilities are to: adhere to and promote the CHRS Guiding Principles; help establish the "common set of HR practices for CSU systemwide”; inform on policy, regulatory requirements, and bargaining agreements; identify greater utilization of delivered functionality to reduce shadow systems; obtain needed information from other key CSU resources; actively participate in the initial prototype build activities |
MyCalPays |
Name given to the State of California’s payroll project. |
Not Supported |
see Out of Scope |
Office of the Chancellor (CO) |
The Office of the Chancellor is the official name for the central office governing the 23 campuses of the California State University. Informally called the Chancellor's Office, and abbreviated CO. |
Operational |
refers to something procedural; or the execution of your strategy or approach |
Oracle/PeopleSoft (PS) |
PeopleSoft was the company who originally owned the PeopleSoft Human Resources, Student Administration and Finance products adopted by the CSU for the CMS project. Oracle bought out PeopleSoft, and the software is now commonly referred to as Oracle, although technically it still retains a “PeopleSoft” technical / development platform. |
Out of Scope |
Not approved to Read / Write either into or out of CHRS |
Parking Lot |
is a place to capture ideas that the team does not want to lose, but are not appropriate to the discussion at hand (either due to time restrictions or the nature of the topic itself) |
Performance Testing |
is testing to evaluate system performance |
Person record |
is the data record of one singular person |
Phase |
or Project Phase, represents the collection of the project activities aimed at a certain end result. Each project phase is goal-oriented and contains a particular number of the work steps to achieve the intended end result. Each phase ends at a milestone, whose attainment means the project has progressed. Each phase can be divided into sub-phases and individual components in a project |
Policy |
is a formal publication from Systemwide Human Resources or Security |
Position Paper |
is a paper that affirms or states one or more of the following: background information, introduction, narrative of an issue, recommendations, considerations, cross functional impacts, for requesting an action/decision |
Process Based Approach for Delivered Functionality |
Using PeopleSoft 9.2 delivered functionality including configuration items and comparing it against the systemwide view |
Project & Change Management Office (PCMO) |
Refers to the project & change management office located at the Chancellor’s Office. |
Project Definition Document (PDD) |
Refers to this document, which delivers the core project information, vision, business justification, scope, budget, and project management and communications approach. |
Project Phase |
see definition for Phase |
Prototype Demonstration |
refers to PeopleSoft 9.2 delivered "Out Of the Box"; also referred to as Conference Room Pilot, an on-going demonstration and a series of workshop sessions to reflect the gathering of input from the Module Leads and workshop participants in order to demonstrate PeopleSoft 9.2 using configuration options, only, no modifications. Multiple conference room pilot demos are intended to take a layered approach to building the groups' understanding of how some of business processes can be addressed by configuring PeopleSoft 9.2 |
Provisioning |
is supplying employees with the tools (email address, network ID) and system access to perform their job. CHRS and other systems (HECH, CS) can enhance the provisioning process by using workflow to automate notifications and alerts when something needs to be done and accurately define what kind of employee they are to know what they should receive |
Quality Assurance Testing |
is a way of preventing mistakes or defects in manufactured products and avoiding problems when delivering solutions or services to customers |
Regression Testing |
is an approach to test the whole application with all the changes applied to ensure that even the unchanged parts of the application still function appropriately |
Recommendations |
is when the team has changed the reference from "decisions" to "recommendations" since the output of this step presents a recommended direction. It is tested to assess how "appropriate/right" the recommendation proves to be until otherwise proven not to work |
Retrofit |
is the process of re-applying a modification after an upgrade or change |
Risk Management Plan |
is a component of the project, program or portfolio management plan that describes how risk management activities will be structured and performed |
Risk Mitigation |
is a response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk |
Scenario |
is a set of test cases that ensure that the business process flows are tested from end to end. They may be independent tests or a series of tests that follow each other, each dependent on the output of the previous one |
Scope |
the sum of the products, services and results to be provided |
Security Conversion |
is the process by which OPERIDs are converted |
SME Lead |
is the Lead Subject Matter Expert. It is the position that provides campus business process, system impacts, and integration expertise. Responsibilities are to: Adhere to and promote the CHRS Guiding Principles; Help establish the "common set of HR practices for CSU systemwide”; Inform on day-to-day campus HR business needs; Provide expertise for system configuration and usability; Obtain needed information from other key CSU resources; Actively participate in the Initial Prototype build activity; Carry out responsibilities of the Campus SME role |
Sponsor |
is a person (campus president, HRO/AVP or leader) who will champion CHRS at the campus and remove barriers. The Sponsor would receive and share regular program updates; communicate CHRS key messages to campus leadership and share campus leadership feedback with CHRS Program Team. The role of sponsor is critical to the success of the CHRS Program. |
Sponsorship |
is the active and visible participation of the leaders who authorized and funded an initiative |
Subject Matter Expert (SME) |
Campus and/or CMS Central staff who are experts in their respective module / technical areas. |
System Guide |
is a guide for the system |
Technical Security |
is the process of implementing measures and systems designed to securely protect and safeguard information (personal data) utilizing various forms of technology developed to create, store, use and exchange such information against any unauthorized access, misuse, malfunction, modification, destruction, or improper disclosure, thereby preserving the value, confidentiality, integrity, availability, intended use and its ability to perform their permitted critical functions |
Test Plan |
is a plan that describes systems test |
Test Scenario |
is a business cases to be tested |
Test Script |
is a list of test scenarios |
Third Party Tools |
are add-on tools that make the product that you buy from a vendor, more useful |
Tracking Log / Tracking Database |
is a SharePoint system used to track all items (Gaps, Parking Lot, Decisions, Action Items) during the Solution Design Activities |
Transaction Data |
is any data tied to a person or job (name, benefit information, title, class, payroll record, labor data, etc. Transaction data is often categorized per module; for example: Administer Workforce would have Administer Workforce transaction data |
Unit System Acceptance |
is full cycle business testing; the testing or QA-ing of units as a result of the conversion process. Unit system acceptance is an integration piece; it is also important to the Application Development team (Lynn's team) |
Unit Test |
is testing to support development |
User Guide |
is a technical communication document intended to give assistance to people using a particular application, program or system |
Wave |
is a group of campuses |
Work stream activities |
are the progressive completion of tasks completed by different groups within the CHRS program which are required to finish a single project. For example, the work stream activity for Application Functionality may include prototype demonstrations |
Functional Terms
The following table includes the module acronyms, as well as terms used within this document in sections describing processes and functionality of each module.
Acronym |
Term |
---|---|
ADD Insurance |
Accidental Death and Dismemberment |
AM |
Absence Management |
ADO |
Additional Days Off |
APDB |
Academic Planning Database |
BEN |
Benefits |
BSA |
Business System Analyst |
CKL |
Checklist |
COBRA |
Consolidated Omnibus Budget Reconciliation Act |
ESP |
Employee Salary Projection |
ESS |
Employee Self Service |
FAC |
Faculty |
FERP |
Faculty Early Retirement Program |
FMLA |
Family Medical Leave Act (tracked through AM) |
GC |
Grants & Contracts |
IPEDS |
Integrated Postsecondary Education Data System |
LCD |
Labor Cost Distribution |
L&D |
Learning & Development |
MPP |
Management Personnel Plan |
MSS |
Manager Self Service |
PIMS / CIRS |
CSU Personnel/Payroll Information Management System / Campus Information Retrieval System |
PM |
Position Management |
REC |
Recruiting |
RTP |
Retention, Tenure and Promotion |
TAE |
Temporary Academic Employment previously Temp Fac |
TDA |
Technical Development Analyst |
T&L |
Time & Labor |
VSP |
Vision Service Plan |
WA |
Workforce Administration |
WTU |
Weighted Teaching Units |
Technical / Infrastructure Terms
Acronym |
Term |
---|---|
DEV |
Development |
IB |
Integration Broker |
PRE |
Pre-production |
PRD |
Production |
SEC |
Security |
STG |
Staging |
TST |
Test |
Committees and Title Acronyms
The following list is not exclusive of all committees involved in the project, it lists those that are referred to by acronym within this document.
Acronym |
Term |
---|---|
AVP |
Academic Vice Presidents |
CABO |
Chief Administrators and Business Officers |
CFO |
Chief Financial Officer |
CIO |
Chief Information Officer |
EC |
CMS Executive Committee |
HRO |
Human Resource Officers |
ITAC |
Information Technology Advisory Committee |
TSC |
Technology Steering Committee |