Common Management Systems (CMS) SA Modification Governance Overview

1. Common Management Systems (CMS) SA Modification Governance Overview January 4, 2005

2. Purpose of Meeting • Informational Meeting • Provide overview of CMS Central & Cal Poly SA Modification Governance processes • Explain affect of CMS & Cal Poly processes to SA Technical Team

3. Agenda • CMS Central Modification Governance • Evolution of Campus Allowed Modifications • COMR Impact Analysis • Cal Poly SA Modification Governance Process Flowchart

4. CMS Central Modification Governance Purpose and Scope • CMS implementation approach • Campuses and the Chancellor’s Office collaborate on functionality through common fit-gap/prototyping effort • Results provide CSU CMS baseline • Campuses will not make local changes to the application code • Campuses can request campus specific changes through the central Software Operations Support and Services (SOSS) group • Campus based reports & interfaces are not considered modifications to SOSS owned tables, so are not under the Modification Governance.

5. CMS Modification Decision Criteria Delivered PeopleSoft functionality (i.e. “Vanilla”) is assumed Proposed modification to PeopleSoft software as delivered will be considered based on: • Modification would impact a campus’ ability to go-live or operate in production environment. • Modification is a result of collective bargaining, trustee requirements, executive direction, or State and/or Federal regulations. • Modification would result in significant reduction in manual effort. • Modification provides a CMS project feature that would maintain a significant service level. • Without modification, additional staff would be necessary to perform the business process.

6. Evolution of Campus Allowed Modifications • Campus reports & interfaces allowed • Campus specific workflow added, including specific triggers in PeopleCode that affect workflow functionality • PeopleSoft delivered self-service functionality, including campus “look and feel” modifications & campus specific warning and error messages • PeopleCode modifications to replace campus 3rd party products or augment Core/Non-Core functionality

7. Campus Modifiable and Non Modifiable Objects • Modifiable • Crystal/nVision/SQR (Reporting tools) • PeopleTools Objects • Records/views • PeopleCode (cloned) • Pages (cloned) • Components (new) • Application Engine programs (cloned or new) • Workflow objects • Non Modifiable • COBOL programs & stored statements • Database-level triggers • CMS Baseline or PeopleSoft Baseline PeopleTools Objects

8. CMS Central COMR Impact Analysis Campus-specific modifications will be subject to a CMS Central impact analysis review process if they meet the following criteria: • Concurrent Users • Transactions that involve 100 or more users, including campus cloning of existing self service. • Production Application Sizing • Permanent changes that will impact DB size by • creating tables • creating indexes • materialized views • Any development that exceeds 1% of a campus' total database size, regardless of type. NOTE: Run control records and temporary tables developed in compliance with CMS guidelines are exempt from impact analysis review unless they exceed the 1% threshold.

9. CMS Central COMR Impact Analysis - Campus PD Review Process

10. CMS Central COMR Impact Analysis - Committee Review Procedure

11. Sample COMR Impact Analysis Forms • Cal Poly – SQR Financial Report and set flags process. • Northridge – Bolt On Screen to provide class schedule info