1 Cal Poly CMS SA Project Common Management Systems (CMS) SA Modification Governance Overview January 4, 2005

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

3 Cal Poly CMS SA Project Agenda  CMS Central Modification Governance  Evolution of Campus Allowed Modifications u COMR Impact Analysis u Cal Poly SA Modification Governance Process Flowchart

4 Cal Poly CMS SA Project CMS Central Modification Governance Purpose and Scope u 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 Cal Poly CMS SA Project CMS Modification Decision Criteria Delivered PeopleSoft functionality (i.e. “Vanilla”) is assumed Proposed modification to PeopleSoft software as delivered will be considered based on: 1. Modification would impact a campus’ ability to go-live or operate in production environment. 2. Modification is a result of collective bargaining, trustee requirements, executive direction, or State and/or Federal regulations. 3. Modification would result in significant reduction in manual effort. 4. Modification provides a CMS project feature that would maintain a significant service level. 5. Without modification, additional staff would be necessary to perform the business process.

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

7 Cal Poly CMS SA Project 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 Cal Poly CMS SA Project 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 Cal Poly CMS SA Project CMS Central COMR Impact Analysis - Campus PD Review Process

10 Cal Poly CMS SA Project CMS Central COMR Impact Analysis - Committee Review Procedure

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

12 Cal Poly CMS SA Project