1Cal Poly CMS SA Project

Common Management Systems (CMS) SA Modification Governance Overview

January 4, 2005

2Cal Poly CMS SA Project

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

3Cal Poly CMS SA Project

Agenda

CMS Central Modification Governance

Evolution of Campus Allowed Modifications

COMR Impact Analysis

Cal Poly SA Modification Governance Process Flowchart

4Cal Poly CMS SA Project

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.

5Cal Poly CMS SA Project

CMS Modification Decision CriteriaDelivered 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.

6Cal 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 3rd party products or augment Core/Non-Core functionality

7Cal 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

8Cal 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.

9Cal Poly CMS SA Project

CMS Central COMR Impact Analysis - Campus PD Review Process

10Cal Poly CMS SA Project

CMS Central COMR Impact Analysis - Committee Review Procedure

Campus OpensService RequestAttaches ImpactAnalysis Form

Change Controllogs request,schedules,

generates reportand distributes

materials tocommittee

Not Approved

Approved

Further Campus Review /Possible Resubmission

Campus PDpresents at

committee meeting

Is not > 10% oforiginal estimate

Exceeds Estimateby > 10%

CompletesDevelopment

Open ServiceRequest forMigration to PRD

Attach COMRMigration Form

Attach FinalImpact AnalysisForm

Complete Section 2 of OriginalImpact Analysis Form, Open New

Service Request, Resubmit

SRTicketClosed

Campus BeginsDevelopment

If modification is a bolt-on, campus mustcomplete a Campus Modification Specification

11Cal Poly CMS SA Project

Sample COMR Impact Analysis Forms

Cal Poly – SQR Financial Report and set flags process.

Northridge – Bolt On Screen to provide class schedule info

12Cal Poly CMS SA Project

Design ReviewBoard

SA TechnicalLead

SA TechnicalStaff

SA Project Lead

SA FunctionalLead

FunctionalRequirement

ProposedFunctional

Specification

FunctionalRequirement

ApprovalProcess

ApprovedFunctional

Specification

No

Yes

ReportingRequirement

ProposedReal Time Report

Specification

Report ApprovalProcess

Data WarehouseReport

Specification

Data WarehouseReport

Specification

ApprovedReal Time Report

Specification

Yes

No

ReportTechnical

Specification

Report

ProposedTechnicall

Specification

DesignStandards

Review

ApprovedTechnical

Specification

StandardsOverrideReview

Does Not Meet Standards,Override Requested

StandardsOverride

Requested,Not

Approved

Meets Standards,Not An Auxilary Application

Modificationor

Aux App

Standards Override, Approved

AuxilaryApplication

DesignReview

AuxApp

DoesNot

MeetStandards,

NoOverride

Requested

PROPOSED Cal Poly Student Administration Modification Governance

AuxApp

Aux App - Approved Tool Selection and Design

Aux App - Design or Tool Selection NOT Approved

What

H

o

w

Yes

Report ApprovalProcess

No