Enterprise Applications Rolling Out “Change Tiers"

Submitted by Jennie Franke

Enterprise Applications (EA)is rolling out “Change Tiers” to provide a framework to our teams guiding process and documentation rigor that is required to support our diverse portfolio of applications-departmental, administrative and enterprise.

Step 1: Evaluate the Risk
For Enterprise Applications, the risk of a change is a combination of complexity and impact. We’ve encountered times when a simple, straightforward data change has broken payroll (resulting in a large impact for the university). And a complex autosys job change might have little impact if it failed (i.e. it could be manually run). Based on this, the teams will evaluate each change with questions like:
Screen Shot

Step 2: Identify the Tier
Based on the risk evaluation, each team will identify which tier applies:
Screen Shot
*EA supports some systems and integrations that allow the business group to make changes. These changes fall outside our control and so have been identified as a separate tier.

**Tier 1 is only for systems with an online application for changes. Lessons learned in EA have lead us to conclude that only these systems are truly low complexity for our department.

NOTE: Because of the scope of systems we support and the intricacies of the integrations it was challenging to create an EA-wide guide for how to apply the tiers. Each team will create their own guide on how the tiers apply to their portfolio of applications.

Step 3: Follow the process and documentation guidelines

Project Documentation: EA System and Project Documents are housed in confluence. For Tier 3 changes, we believe that we can address all required content within a single Confluence page. Whereas for Tier 4, we would expect a full requirements document, full user test scripts, etc.

Our required content for Tier 3 and 4 is called a PAC(Program Authorization Change), and includes:

Request for work-Requirements
Design-System Test Plan/Scripts
User Test Plan/Scripts
User Authorization
Implementation Checklist

EA TTO Meeting: EA has established a standing “Transition to Operations” meeting as a final check for any change moving into production to ensure that the proper information and context is provided to allow our Production and Operations (ProdOps)team to appropriately support the change in the production environment.

ServiceNow: We require any change Tier 2 or higher to have a Change Request in ServiceNow. The troubleshooting process for production involves evaluating change requests, so without this, the troubleshooting could take longer.

Change Requests/CAB: For EA, we’ve determined that even Standard changes fall into our Tier 2 in terms of EA Process and documentation requirements.

EA’s change process will be a living process and will change as we gain experience working in this model. We look to continually improve our processes over time in order to continue to mature and deliver quality support and projects to the University.