SPEBO_Release_Management_Plan_Redacted.pdf

Release Management Plan SSP Navy ERP Business Office (SPEBO) Version 2.0

Strategic Systems Programs

12/4/2017

SPEBO Release Management Plan_20171204 Final.docx Page 3 of 24

Executive Summary

Navy ERP was deployed across the Strategic Systems Programs (SSP) Enterprise in October 2012, which created an integrated network of business processes and business activities across the organization. The SSP Navy Enterprise Resource Planning (ERP) Business Office (SPEBO) ensures the day-to-day execution of the Navy ERP solution is optimized to increase operational efficiency and effectiveness, while enhancing solutions for business processes at SSP. For additional information regarding how the SPEBO operates during the sustainment period and provides support to SSP end users and business processes within the Navy ERP environment, see Reference A.

The SPEBO’s primary focus is to improve the end user experience in Navy ERP by providing subject matter expertise, championing customer requirements, and facilitating smart solutions.

The SPEBO resolves issues by providing problem resolution functions to end users throughout the command, and also by serving as a direct link to SSP Business Process Owners. In some instances, changes emanating from leadership, end users, process representatives, business process owners, or stakeholders may be needed to enhance or correct the solution to accommodate SSP business processes.

This SPEBO Release Management Plan (RMP) outlines the processes and procedures that are performed to support Service Requests, Defect Management, Design Changes, and Engineering Change Proposals (ECPs) as part of the ongoing effort to optimize SSP business processes. This RMP is a key component in describing how these changes are facilitated and managed. The RMP:

• Describes the high-level approach and processes the SPEBO follows in managing changes to the Navy ERP Production environment;

• Defines high-level roles and responsibilities; and

• Defines key activities necessary to establish and support release management across the SSP Enterprise.

This RMP is intended to serve as a guide for the SPEBO’s Director and Deputy Director regarding interaction with the Navy ERP Program Office (PO) and the Navy Enterprises Business Solutions (NAVEBS) Office in validating proposed changes through the Quality Center (QC) tool, implementing and testing various production releases, and mitigating any negative impact from the production releases. Additionally, the plan ensures that the SPEBO team, Field Activity (FA) Site Leads, and Business Process Owners are aware of the processes and procedures that are necessary to support release management of the Navy ERP solution.

SPEBO Release Management Plan_20171204 Final.docx Page 4 of 24

Table of Contents

1.0 Introduction

1.1 Reference Documents

2.0 Program Management

2.1 Program Management Approach

2.2 Roles and Responsibilities

2.2.1 Business Office Director

2.2.2 Business Office Deputy Director

2.2.3 SPEBO Team Leads

2.3 Release Management Governance Process and External Organizations

2.3.1 Executive Steering Group

2.3.2 Navy ERP Senior Board

2.3.3 Navy ERP Working Group

2.3.3.1 Process Councils

2.3.4 Command Requirements Review Board

2.3.5 Stakeholder Release Review Group

3.0 Release Management Lifecycle

3.1 Incident Management Process

3.1.1 Defect

3.1.2 Request for Change

3.1.3 Action Item

3.1.4 Engineering Change Proposal

3.1.5 Emergency Work Releases

3.2 Scheduled Release Management Process

3.3 Unscheduled Release Management Process

3.4 Testing and Validation

3.4.1 Regression Testing

3.4.2 Functional Testing and Validation

4.0 SPEBO Release Management Process

4.1 Sustainment Item/Heat Ticket Management Process

4.2 SPEBO Incident Management Process

5.0 Communications

SPEBO Release Management Plan_20171204 Final.docx Page 5 of 24

5.1 Release Notes

6.0 Acronyms

Table of Figures Figure 2-1 Navy ERP RM Governance Structure Figure 3-1 Incident Management Process Figure 3-2 SSP Enterprise: Scheduled Release Management Process Figure 3-3 SSP Enterprise: Unscheduled Release Management Process

SPEBO Release Management Plan_20171204 Final.docx Page 6 of 24

1.0 Introduction

Release management is defined as the process of managing, planning, scheduling, and controlling a software/application through different stages and environments. The SPEBO RMP defines the approach, methodology, and processes for release management of the Navy ERP solution across the SSP Command. This plan serves as a guide for the SPEBO’s release management operations and should be considered the source for roles and responsibilities, defined approaches, and key activities necessary to establish and maintain release management activities for the command.

The SPEBO’s RMP addresses and describes the following:

• SSP’s and the SPEBO’s approach to release management.

• SPEBO Roles and Responsibilities.

• Release management Governance Structure. Framework established by which the Navy addresses release management issues and approves changes relative to the sustainment of Navy ERP.

• Navy ERP Incident Management Process that consists of the systematic tracking, impact ranking, testing, and the validation of Quality Center Items (QCIs) in Navy ERP.

• Production Release Process – Scheduled and Un-Scheduled. The systematic process of controlling, testing, and validating changes affecting SSP business processes that are promoted to the production environment via a scheduled or unscheduled release originating from QC.

• SSP release management process. Process for controlling, testing, and validating SSP defects and Request for Change (RFC) and the high level steps on how these changes, affecting SSP business processes, are promoted to the production environment via a scheduled or unscheduled release.

Note, in this document, Navy ERP Program Office (PO) is used to refer to the NAVEBS, the Naval Supply Systems Command’s (NAVSUP) Business Systems Center (BSC), which leads Enterprise Integration, and the Space and Naval Warfare Systems Command’s (SPAWAR) Systems Center (SSC) Atlantic, which leads Enterprise Operations.

1.1 Reference Documents

• Reference A - SSP ERP Business Office Sustainment Plan – (October 2016)

• Reference B - Navy ERP Program Office ECP Process

• Reference C - SSP ERP Business Office Governance – (November 2016)

For an electronic version of these documents, email SSPERP@ssp.navy.mil or visit the following site: https://sphqdm1.sphq.ssp.navy.mil/Livelink/livelink.exe?func=ll&objId=3185988.

SPEBO Release Management Plan_20171204 Final.docx Page 7 of 24

2.0 Program Management

2.1 Program Management Approach

The SPEBO serves as the Navy ERP champion within the organization, acting as the primary agent to facilitate the use of Navy ERP functionality on behalf of the Command. The SPEBO coordinates across the SSP Headquarters (HQ) branches and FAs to identify and communicate SSP specific issues and actions that impact external customers and agencies. The SPEBO maintains strong liaisons with the Navy ERP Sustainment organizations (NAVEBS PMW220, SPAWAR SSC-LANT and NAVSUP BSC), other Command Navy ERP Business Offices (CBOs), SSP HQ branches, and field activities. The SPEBO Deputy Director manages the release management efforts for the Command throughout the sustainment of the Navy ERP solution and is responsible for oversight and coordination of the release management activities for the SPEBO.

2.2 Roles and Responsibilities

2.2.1 Business Office Director

The SPEBO Director monitors the use of the Navy ERP system at SSP to ensure that the system is operating as intended for all end users and that they receive timely feedback on issues and resolutions. The Director also closely monitors metrics to ensure business performance metrics meet the acceptable thresholds and objectives. With respect to release management, the Director’s responsibilities include:

• Approve the RMP.

• Assist in the prioritization and submission of requirements to the Business Process

Owners and brief them on the submissions to gain their approval.

• Plan and allocate resources to ensure successful execution of the RMP.

• Communicate, as required, to SSP leadership/Board of Directors (BOD).

2.2.2 Business Office Deputy Director

The SPEBO Deputy Director is responsible for providing support as needed to the SPEBO Director and oversees, on behalf of SSP, release management activities and processes contained within the RMP. While in the RMP the Deputy Director is the Release Manager, the Deputy Director has authority to identify and assign the Release Manager duties and/or activities to another SPEBO representative. The Deputy Director’s responsibilities include:

• Develop and maintain the RMP.

• Monitor the Navy ERP Defect Tracking Tool, QC, for new items entered and updates to existing defects in order to provide the information to the SPEBO Team Leads, and post the information to SSP Livelink.

• Work with SPEBO Team Leads to generate SSP defect priorities, update QC with scope and severity-related information, and post updated SSP QC master list on Livelink.

• Generate and post reports of planned release items and the status of the quarterly scheduled release dates.

SPEBO Release Management Plan_20171204 Final.docx Page 8 of 24

• Distribute unscheduled release reports to the SPEBO Team Leads and post to Livelink.

• Coordinate all SSP testing activities with the Navy ERP PO in accordance with Defect &

Regression Testing Procedures.

• Lead and coordinate all SSP ECP submissions.

• Prepare release management briefings, reports, and documents to support proactive program management as required.

• Participate in all external release management groups and meetings, validate priorities, and ensure SSP business interests are met.

• Maintain a roster of potential testers to call upon for future testing.

• Post reports of planned release items and status of the quarterly scheduled release dates.

2.2.3 SPEBO Team Leads

The SPEBO Team consists of the following leads: Business Process, Production Operations, Business Intelligence, and Customer Liaison. The Team Leads perform defect impact assessments, support testing and validation of defects affecting SSP business processes, and act as a liaison to the SSP end user community for establishing test teams and identifying test participants. The SPEBO Team Leads responsibilities include:

• Review and recommend changes to the overall RMP based on lessons learned.

• Review and assign SSP impact, scope/severity, impact description, priority, testing requirements and validation on QC tracking items that fall within their teams review.

• Review release notes and ensure learning aids are updated as required.

• Serve as or solicit testers and/or validators for items that are scheduled to be released into production.

• Review and provide comments on ECPs prepared by and for SSP and other

Commands.

• Communicate with the end users on information related to HEAT Tickets that were entered, such as the status on the item and when it will be released.

• Provide input to SSP’s list of Top 10 Command Priority rankings.

2.3 Release Management Governance Process and External Organizations Throughout the sustainment of Navy ERP, there are opportunities for process efficiencies, cost savings, manual workload elimination, and general ease of use through system enhancements discovered after initial deployment. These opportunities may be identified by end users, Business Process Owners, stakeholders, and/or SPEBO personnel. Figure 2-1, below, depicts the high level governance framework that has been established by which the Navy addresses release management issues and approves changes relative to the sustainment of Navy ERP.

External organizations involved in Navy ERP release management activities and RM governance process are briefly described following Figure 2-1.

SPEBO Release Management Plan_20171204 Final.docx Page 9 of 24

For additional information regarding SPEBO’s overall governance strategy and how critical business decisions that impact SSP’s ongoing execution and sustainment of the Navy ERP solution are identified, escalated, and adjudicated, see Reference C.

Figure 2-1 Navy ERP RM Governance Structure

2.3.1 Executive Steering Group

The Executive Steering Group (ESG) provides direction and approves major decisions, including annual work plans and rules for execution year deviations. The ESG owns the decision model for validating, prioritizing, and scheduling work. It performs budget and service level review and recommends Program Objective Memorandum (POM) and Navy Working Capital Fund issues. The ESG interprets policy and strategy to drive Navy ERP strategic priorities and policy, and assesses policy for potential conflicts.

2.3.2 Navy ERP Senior Board

The Navy ERP Senior Board (SB) is responsible for translating ESG guidance into governance decisions, synthesizing strategy and policy from the ESG, and providing direction to the Working Group to guide implementation. The SB prioritizes work proposals as inputs to the work plan and master schedule. The SB reviews risks and issues to ensure clear risk mitigation plans and issue resolutions plans exist.

Executive Steering Group

(ESG)

Gate 6

DON BTC CHAIR: UNSECNAV

CHAIRS: ASN(RDA) & VCNO

CHAIR: OPNAV N4B

• PDASN(FM&C)

• PCDASN(RD&A)

• DUSN(M) BO

Navy ERP Senior Board

(SB)

CHAIR: OPNAV N41

• DASNs: FMO, FMP, C4I, ELM, AP; OCHR

• In-Scope BSO EDs

• PEO-EIS & PMO

Navy ERP WG

(WG)

CHAIR: OPNAV N414

• O-6/GS-15 AOs for SB … includes CBO Directors & PMO

Work Mgmt IPT Tier 3 Help Desk Tier 2 Help Desk Tier 1 Help Desk

• DASN(CHR)

• Advisors: DDCIO-N, Senior Board Members

SPEBO Release Management Plan_20171204 Final.docx Page 10 of 24

2.3.3 Navy ERP Working Group

The Navy ERP Working Group is responsible for proposing options for prioritized work plans, resource and service levels, and business capabilities and metrics. The Working Group focuses on new functional or technical topics and matters of policy. The Working Group may assign work to the Navy ERP Program Office and/or other management forums. Decisions that have non-trivial impacts on cost, schedule, and performance are returned to the Working Group for adjudication.

2.3.3.1 Process Councils

As part of the Navy ERP Working Group, process councils have been identified for each functional business area. The current process councils are Supply, Finance, Workforce Management, and Acquisition. There is a designation for a Maintenance Process Council which has yet to be established. Each process council serves as the entry point for the Command Business Offices (CBO) when identifying functional capabilities for Navy ERP. Process Councils meet on an as-needed basis to provide a forum for examining requirements within a specific functional area. It is the responsibility for each CBO to elevate specific requirements to the appropriate Process Council in order to have a fully collaborative discussion with all Systems Commands (SYSCOMs) represented. Each Process Council is responsible for bringing forward well-developed, documented, and prioritized program requirements for Navy ERP within their functional area.

2.3.4 Command Requirements Review Board

The Command Requirements Review Board (CRRB) was established to help discern customers’ needs to NAVEBS PMW220, SSC LANT, and NAVSUP BSC. The CRRB is comprised of a representative from each Navy ERP SYSCOM, with the SPEBO RM representing SSP. The CRRB chair is rotated every quarter amongst its members and while the CRRB strives for a consensus, decisions are based on majority rule. The goals of the CRRB are to define the types of work and business rules surrounding the work that SSC Lant and NAVSUP BSC are performing; prioritize sustainment work within each process area to assist in the completion of a scheduled production release work plan each year; define how the current toolsets within NAVEBS PMW220 shall meet the goals of the CRRB; and ensure the BSC resource matrix is appropriate to complete the prioritized work. The CRRB provides input and communicates to the process council and NAVEBS PMW220, SSC Lant, NAVSUP BSC, and advises the Navy ERP Working Group.

2.3.5 Stakeholder Release Review Group

The NAVSUP BSC facilitates a bi-weekly session to discuss the status of QC Items in a release.

Participants include CBO representatives that are members of the CRRB, and Tier 3 leads. The purpose of the Stakeholder Release Review Group is to review and validate relative priorities for changes to the Navy ERP system, confirm appropriate resources are applied, achieve alignment on schedule assignments, negotiate changes in priority, and determine testing requirements. The Release Manager is the primary SPEBO representative to this group.

SPEBO Release Management Plan_20171204 Final.docx Page 11 of 24

The Stakeholder Release Review Group is chaired by the NAVSUP BSC Release Manager, who is responsible for communicating all production scheduling requirements and changes to the Navy ERP CBOs. The Stakeholder Release Review Group:

• Identifies items to schedule, thereby creating and maintaining a production release schedule

• Provides release schedule assignments to its members and conducts bi-weekly meetings to negotiate and obtain alignment on the release order.

• Develops and distributes release notes for each scheduled release.

• Identifies the release information required to be received by the Communications Lead.

3.0 Release Management Lifecycle

Release management is the systematic process of controlling and testing changes to the Navy ERP production environment that may impact the Navy SYCOMS. Changes to the production environment need to be evaluated and grouped into categories that assess the impact to the Navy ERP system. These range from changes that are low risk which require minimal or no testing to high-complexity and high-risk changes that must be thoroughly tested to ensure that the changes will not unintentionally alter existing functionality in production. Typical changes in Navy ERP during Sustainment may include:

• Functional changes based on identified system trouble reports (defects).

• SAP or Oracle patches and SAP On-line SAP Support notes.

• Changes to interfaces and bolt-on applications that integrate with SAP.

• ECPs or Design Changes.

• New Navy ERP end user, business office roles or changes to existing roles.

Production changes are grouped, when possible, into functional packages to allow for a more consistent testing approach while minimizing the business area impact of the specific release.

Further, the scope of each production release is determined by the integration complexity of the business/technical requirement, resource availability and business criticality. The Navy ERP PO uses the following criteria (at a minimum) to assess inclusion into a Production Release Package:

• Amount of work required to implement a particular change.

• Impact of the need for the functionality/correction.

• Effective date of changes for interface requirements.

• Resources available for building, testing, distributing, implementing, and communicating the change.

One of the RM’s key focus areas is internal SPEBO coordination of defects, change requests, and ECPs. The focus is to ensure these items are tracked for scheduling in a release based on SSP priority, developed, transported through the landscape by the Navy ERP PO, tested by the

SPEBO Release Management Plan_20171204 Final.docx Page 12 of 24

Navy ERP PO and SSP as needed, and then validated once promoted to the Production environment.

The following sections describe the overall Navy ERP PO Incident Management Process and processes SSP follows to support release management throughout sustainment of Navy ERP.

3.1 Incident Management Process

The SYSCOMs and Navy ERP PO collectively use tools such as the Help Desk Expert Automation Tool (HEAT) and the QC tracking system to log and track system issues. One of the CBO’s key focus areas is managing incidents, which begins with HEAT tickets that may become a defect, request for change (RFC), emergency work request (EWR), or ECP. SSP end users experiencing a Navy ERP-related issue should first determine if the available self-help tools, such as learning aids or peer support, can provide assistance. If self-help tools do not resolve the issue, the user should contact the SPEBO. If the SPEBO is unable to resolve the issue, a HEAT ticket is created, which is assigned a priority, one through three, based on criticality. The priority of a trouble ticket defines the importance of that incident.

All Navy ERP trouble tickets are routed through the National Help Desk (NHD), which is comprised of several tiers to denote levels of expertise required to resolve the tickets:

• Tier 1 – The National Help Desk (NHD) receives the user’s initial call or web submittal.

These agents provide high-level support and resolve basic user issues.

• Tier 1.5 – These agents are also part of the NHD and receive calls that Tier 1 cannot resolve. These personnel have a greater depth of knowledge for specific issues related to Navy ERP, as they utilize training materials and tip sheets to assist in providing resolution. If Tier 1.5 is unable to resolve the ticket successfully, it is reassigned to the next tier of agents.

• Tier 2 - These agents reside within the CBOs. For SSP, SPEBO personnel are the Tier 2 agents and receive HEAT tickets that could not be resolved at the Tier 1 levels. Tier 2 works with the user who submitted the issue to assess the problem and provide a resolution. In some cases, Tier 2 may not have the access needed to resolve a ticket or encounters a system issue that prohibits resolution and reassigns the ticket to Tier 3.

• Tier 3 – Personnel from the BSC provide Navy ERP Tier 3 support. If Tier 3 cannot resolve a trouble ticket by correcting data or performing an action to fix the issue and determines a system change/correction is required, the HEAT ticket is then logged into QC, the Incident Tracking Tool, as a defect and is assigned a tracking number.

In certain instances, a HEAT ticket is submitted for a maintenance item. These tickets are identified as a Service Request and assigned to Tier 3 for immediate action. These maintenance items allow work to continue and may involve actions such as adding master data for which Tier 2 personnel do not have access, unlocking documents stuck in workflow, updating data that has not derived in the correct manner, or performing table updates.

SPEBO Release Management Plan_20171204 Final.docx Page 13 of 24

The Incident Management Process (Figure 3-1), depicts the process in which a HEAT Ticket submitted by an end user is escalated to Tier 3, as it could not be resolved at a lower level.

Additional details regarding Figure 3-1 are provided in section 3.1.1 through 3.1.5. Table 3-1, summarizes the difference between a HEAT Ticket, defect, RFC, action item, RFC, ECP and

EWR.

Figure 3-1 Incident Management Process

HEAT ticket is received at Tier 3 (Tier 1 or 2 could not resolve)

No

En d

Us er

St ak eh ol de r Na vy E

RP

P

O

SP

EB

O

O pe ra tio ns

Bu sin es s Pr oc es s Te am (T ie r 2

SP

EB

O R el ea se

M an ag er

Enterprise Incident Management Process

Issue is identified and submitted for resolution via a

HEAT ticket

Is the issue a Defect?

Is the issue a Request for

Change (RFC)?

Is the issue an Action Item? NoNo

Scheduled Release

Mgmt Process

17 August 2017

Is the issue an ECP? No

Issue is resolved via the HEAT

Ticket Resolution Process

Yes

Incident is acknowledged and sent to SPEBO

Ticket is acknowledged and routed to the

SPEBO RM

Does RM agree with ECP identification?

Yes

The item is logged in QC and incident number is noted in HEAT Ticket before sending back to

SPEBO

Yes Yes

Is this an Action Item?

Unscheduled Release

Mgmt Process

No

Yes

Validate that the HEAT ticket number is associated to the Quality Center item in QC

Is this item an Emergency Work Release (EWR?)

EWR Mgmt Process

Yes

No

Journal Entry is made, customer is contacted and HEAT Ticket is closed

SSP ECP

ProcessYesTicket is sent back to

Tier 3 No

SPEBO Release Management Plan_20171204 Final.docx Page 14 of 24

Heat Ticket Defect - Break Fix Defect - Design Change Defect - Change Request

(CR)

Engineering Change

Proposal (ECP)

Description

User requires assistance beyond what is available from self-help tools.

Examples:

• How to

• Service Request

• Data clean up

• System access

• Printing

• System performance

• Locked record

• Work stoppage

• Expected action did not occur

• Short dump

Requires a fix or update to the Navy ERP system because the software was configured or coded incorrectly

Occurs during testing, when operation is affected by a change or when the wrong outcome results from the original requirement set.

A change to existing design that optimizes functionality but does not add or delete capability.

Examples: modify an existing report, change an existing process to improve efficiency and/or effectiveness

Requires the addition or removal of Navy ERP functional capabilities to the Navy ERP Program Scope, e.g., implementing the Grants Management module for Office of Naval Research (ONR), NAVSEA complex contracting process.

Created by

Any Navy ERP end user Identified by any Navy ERP end user, but logged into Quality Center by Navy ERP personnel

Identified by any Navy ERP end user, but logged into Quality Center by Navy ERP personnel

Identified by any Navy ERP end user, but logged into Quality Center by Navy ERP personnel

Identified by SSP end user and presented to the SPEBO Release Manager to follow the ECP Process

Solved By

• Tier 1/1.5 Helpdesk

• Tier 2 NEBO

• Navy ERP Tier 3

Navy ERP Tier 3 Navy ERP Tier 3 Navy ERP Tier 3 Navy ERP Tier 3

Table 3-1 Incident Tracking

As SSP end users encounter or detect issues with the Navy ERP production systems, the end user should report the incident to the Help Desk via a HEAT ticket or phone call to document and track their issue. If Tier 1, Tier 1.5, nor Tier 2 personnel are unable to correct the incident identified in the Help Desk ticket, the ticket is routed to Navy ERP PO Tier 3 which categorizes the incident into several “buckets” or queues awaiting further action. The queues are described below.

3.1.1 Defect

Issues resulting from functionality that is not developed correctly to meet specified requirements are called defects. Once Navy ERP PO determines that the incident is a defect, they enter the item in the Sustainment Project of QC. Now called a QC Item (QCI), it is assigned to their development team for correction. The auto-generated number assigned to the QCI becomes the primary tracking reference for the issue going forward in the release management process. After Navy ERP PO has logged the item in QC, they make a note of the new QC tracking number and route the HEAT ticket to the appropriate SPEBO Tier 2 team. SPEBO Tier 2 validates that the HEAT ticket number has been entered into the HEAT Ticket # field within QC, notifies the customer that their issue has been entered as a defect, copies this correspondence into the journal of the ticket and closes it. Navy ERP PO begins the Scheduled release management process for the item (refer to section 3.2).

3.1.2 Request for Change

A request for change (RFC) requires a design change to existing functionality in the Navy ERP solution to accommodate business requirements. Once Navy ERP PO determines that the incident is an RFC, they enter the item in the Sustainment Project of QC and, as with defects, the auto-generated number becomes the primary tracking reference through the release

SPEBO Release Management Plan_20171204 Final.docx Page 15 of 24 management process. Navy ERP PO should make a note of this new tracking number in the HEAT ticket prior to sending the ticket back to the appropriate SPEBO Tier 2 team. Once received, SPEBO Tier 2 validates that the HEAT ticket is referenced in the appropriate field in QC, notifies the customer that their issue has been entered as an RFC, copies this correspondence into the journal of the ticket and closes it. Navy ERP PO begins the scheduled release management process for the item (refer to section 3.2)

3.1.3 Action Item

An action item incident occurs when data needs to be manipulated and only the Navy ERP PO Tier 3 functional team can perform the action. Once the Navy ERP PO determines that the incident requires their action, they enter the item in the Sustainment Project of QC. When the item is logged, an auto-generated number gets assigned and becomes the main number for tracking the item throughout the release management process. The Navy ERP PO then begins the Unscheduled release management Process for the item (more detail in Section 3.3). After the Navy ERP PO has logged the item, they then route the HEAT ticket item to the appropriate SPEBO Tier 2 HEAT queue. The SPEBO Tier 2 functional team member ensures that the HEAT ticket number has been entered into the tracking item within QC and then closes the ticket.

3.1.4 Engineering Change Proposal

Throughout Sustainment, there are opportunities for process efficiencies, cost savings, manual workload elimination, and general ease of use through system enhancements discovered after initial deployment. ECPs are the result of issues that require a new capability or a removal of capability to the Navy ERP program scope. Such capabilities may be generated for many reasons and from many sources; once introduced, however, all requests follow the same processes for configuration change and release management. End users, process owners, or stakeholders may propose a new capability and route it to the Navy ERP PO when they identify:

• Process improvement opportunities that reduce manual effort and cost, or improve business process performance such as cycle time, accuracy, quality, or compliance.

• Performance deficiencies or benefit opportunities affected by the Navy ERP solution as identified by business process metrics.

If the Navy ERP PO determines that the trouble ticket is an ECP, the ECP process begins and the ticket is routed to SPEBO Tier 2. Tier 2 notifies the customer that their issue has been entered as an ECP and closes the ticket. The incident is now part of the formal ECP process.

For additional information and guidance on the ECP Process, see Reference B.

3.1.5 Emergency Work Releases

Some issues may require immediate resolution and are raised as Emergency Work Releases (EWRs). To be classified as an EWR the defect should be impact 1 with a scope and severity of 1 (see table 4-1). These items are raised to the CRRB Chair for review and concurrence by the SYSCOMs CRRB leads. Once approved, Navy ERP PO is made aware of the EWR and provides the QCI tradeoffs, if any, back to the CRRB which items will not be worked and/or

SPEBO Release Management Plan_20171204 Final.docx Page 16 of 24 finished as a result of moving resources to the EWR. EWRs can be released via either a scheduled or unscheduled release.

3.2 Scheduled Release Management Process

Scheduled Production Releases occur on a quarterly basis by the Navy ERP PO. These releases can include RFCs, ECPs, break-fix corrections, security changes, hardware updates, etc. and these production releases are functional or technical releases. The Navy ERP PO has a defined process for scheduling and managing a production release, which includes all functional, technical, and test documentation associated with applicable items, training material updates, release notes, and functional and regression testing.

Navy ERP PO publishes a Navy ERP scheduled release calendar each fiscal year that contains the scheduled release dates, the regression test window, the cutoff date for adding items to upcoming releases, and Technical Configuration Control Board (TCCB) dates for regression and production. Currently, there is one scheduled release each quarter. Functionality is transported early Sunday morning at the end of the weekly maintenance window on the date of the scheduled release. The overall process of the Scheduled Release Management process is shown in Figure 3-2, Scheduled release management Process. For each Scheduled Production Release, Navy ERP PO provides release notes that provide an explanation of the changes being incorporated into the production environment. The SPEBO Release Manager updates the release notes to create a user-friendly version that is then distributed to SPEBO Team members for their review and to update, learning aids, as required.

3.3 Unscheduled Release Management Process

Unscheduled Production Releases are used on an as needed basis to account for data changes, security changes, critical system changes, or other mission-critical software or hardware updates. A production release is not considered a technical release and is not associated with a specific production release name. Refer to Figure 3-3 for the Unscheduled Release Management Process. The Navy ERP PO distributes the unscheduled release meeting minutes to the Release Manager. For the items approved for release that day, the SPEBO RM highlights those items and forward the results to the SPEBO Team Leads and post the report(s) to Livelink.

Once the Navy ERP PO determines that a situation arose from receiving a trouble ticket through the incident management process (refer to section 4.1), they analyze the actions needed to resolve the issue and take corrective action. The Navy ERP PO team submits the corrective action via a Change Request Management (ChaRM) project, release through the landscape, and test in each of the environments. Once all testing is completed in the test environments, the Navy ERP PO functional sponsor represents the item at the TCCB by addressing the problem, the correction, and its test results. The Navy ERP Production Manager, or designee, either approves the item for release into Production for that day (or another specified date) or defers the item to allow the functional sponsor to address questions or actions from the TCCB and present the item again at a future TCCB when all actions and questions are completed.

SPEBO Release Management Plan_20171204 Final.docx Page 17 of 24

Figure 3-2 SSP Enterprise: Scheduled Release Management Process

Figure 3-3 SSP Enterprise: Unscheduled Release Management Process

Enterprise Scheduled Release Management Process

N a v y E

R P

T ie r

S P

E B

O B u s in e s s P ro c e s a n d P ro d u c ti o n O p e ra ti o n

T e a m s

S P

E B

O R e le a e a n a g e r

T e s te rs

17 August 2017

End

Legend Manual Process

Integration Point

Navy ERP Transaction

Automated (not Navy ERP)Interface

Schedule Tracking Item to be Included in Quarterly Planned Release

Review and Comment

Make Updates to FDS as Required & Send to Commands for Review

Start

Concur with Updated FDS?

NO

YES

Receive FDS Updates and Send to Team Leads for

Review

Receive Comments and Send to Navy

ERP Tier 3

5b

Create ChaRM and Move to RD Box for

Developmental Testing

5a

Create QCI and Move to RU Box for Command Testing

Testing via

DCO?

YES

NO

Attend DCO Testing

7a

Identify Testers

7b

Testers Have Access to RU?

YES

NO

Perform Testing in

RU

8a

Submit Testers for RU Access and

Track to Completion

8b

Testing Successful?

YES

NO

Update Code Based on Test Results

9b

Release QCI Into Production

9a

Conduct Regression Testing to Check for

Error Messages

Send Release Notes to Team Leads and

Post to Livelink

Validate (Involve Relevant Testers If

Applicable)

Notify End Users and Update HEAT

Tickets

13a

Validation Successful?

YES

NO

Reopen the QCI

13b

Enterprise Unscheduled Release Management Process

N av y E

R P

T ie r 3 S

P E

B O

B us in es s P ro ce ss d

P ro du ct io n

O pe ra tio ns

Te am s

S S

P N av y

E R

P E nd

U r S

P E

B O

R el ag er

17 August 2017

End

Legend Manual Process

Integration Point

Navy ERP Transaction

Automated (not Navy ERP)Interface

Analyze Issue and Determine

Corrective Action

Complete Testing in All Environments

Submit Corrective Action via a ChaRM

Project Start

1 3

Testing Successful?

NO

Item is Presented to TCCB to Include

Corrective Actions and Testing Results

YES TCCB

Approved?

Publish Unscheduled

Release Notes

YES

4a

5a

Review Unscheduled

Release Notes for SSP-specific Items

Send Unscheduled Release Notes to

Module Leads and Post to Livelink

Validation Required?

Notify End Users with HEAT Tickets

Associated to Release Items

Receive Notification with HEAT Tickets

Associated to Release Items

NO

8b

Update QC with Validation

Information for Release Items

Validate (Involve Relevant End Users if Applicable)

YES

Validate (if Applicable)

Validation Successful?

NO

YES

Notify Navy ERP PO to Reopen the Tracking Item

Update QC with Validation ResultsNotify SPEBO RM

Validate that Tracking Item is Closed in QC

8a9

9a

10a11

12 10b

SPEBO Release Management Plan_20171204 Final.docx Page 18 of 24

3.4 Testing and Validation

3.4.1 Regression Testing

All scheduled Navy ERP releases, including minor releases, bug fixes, and service requests are tested by the Navy ERP PO. This testing includes regression testing to preclude unintended effects on the production system and command users. The SPEBO may be asked to participate in certain ongoing test evolutions depending on the business processes involved and potential impact to the command. The approach used for regression testing for a release changes based on the type and complexity of the release. The regression tests are mostly automated through QC Quick Test Pro to ensure the systems continue to function with the newly implemented changes.

3.4.2 Functional Testing and Validation

When the tests are completed and successful, the testers provide the results to the SPEBO RM who loads the test results into QC. If the test was not successful, a comment must be entered into QC with an explanation as to why the test failed. The tester notifies the Navy ERP PO of the negative result who logs a defect in the Regression Project in accordance with the Navy ERP Regression Standard Operating Procedure. The Navy ERP PO functional lead receives the defect and takes the necessary steps to resolve it. Upon resolution, the Navy ERP PO functional lead assigns the defect back to the Navy ERP PO Configuration Manager who then notifies the tester(s) to retest. An iteration of the previous steps continue until the defect is corrected.

When all scheduled items have passed testing, the Navy ERP PO conducts their TCCB to gain approval to transport the package to production. As the package is transported to the production environment, in accordance with the quarterly release schedule, the SPEBO RM receives and distributes the Post Release Report to the SPEBO team. If there are any items that were scheduled to go into production, but do not due to failed testing, the Customer Liaison Team provides the necessary communication to the affected SSP end user audience. At this time, the SPEBO Team Leads should determine whether they (or designee) will validate that the item has been corrected in production and the Command Validation field in QC should be updated accordingly. A command has two weeks from the time an item is transported into production to validate the item. If more time is needed because the item is dependent on an event, such as period end close or quarterly reporting, then the SPEBO RM extends the estimated completion date by entering a comment in QC for that item. If validation is unsuccessful, the SPEBO RM should notify the Navy ERP PO functional lead to reopen the item. The process repeats until the item is corrected. Note that performing validation in the production environment is mandatory for any item designated in QC as a SSP Command Priority; therefore, the steps above for participating in validation must be followed.

SPEBO Release Management Plan_20171204 Final.docx Page 19 of 24

4.0 SPEBO Release Management Process

4.1 Sustainment Item/Heat Ticket Management Process

In order to track and manage items that are entered into the QC Sustainment Project, the SPEBO must be able to correlate a QCI to a trouble ticket (HEAT), and track, prioritize, and potentially test items that are related to SSP business processes to ensure all items needing correction or modification are fixed and are successfully promoted to the production environment. This capability is tied to the incident management process as a trouble ticket that is processed as either a design change or defect by Navy ERP Tier 3. In order to ensure that an SSP customer who submits a trouble ticket receives status on their incident submission, Tier 2 SPEBO personnel complete the HEAT Ticket # field and enter SSP heat ticket in the SSP Notes field in QC. As this data entry is completed, a link between the trouble ticket number (and ultimately the end user) and the QC sustainment tracking item is established. This allows those at the SPEBO to identify tracking items that have been opened because an SSP customer placed a trouble ticket and also allows for better filtering, reporting, and tracking in the QC tool.

Once the QCI is created and the HEAT ticket and QCI relationship is established, the next step is to determine the impact of each item.

4.2 SPEBO Incident Management Process

On a weekly basis, the SPEBO generates a data extract from QC. The file contains all new items generated during the previous week in the QC Sustainment Project. The new QC items are identified in a No Scope or Severity spreadsheet and provided to Team Leads for review.

SPEBO Team Leads review each QC item under their purview and update the spreadsheet to include Scope/Severity, Testing Type, Name of Tester, and SSP Priority and send it back to the SPEBO RM to consolidate responses and update QC.

In order to assist in the impact assessment, the Universal Prioritization Schema (UPS) is used to designate the SSP impact on QCIs, see figure 4-1 for UPS model.

SPEBO Release Management Plan_20171204 Final.docx Page 20 of 24

Figure 4-1: Universal Prioritization Schema

The impact rating references the QC database column SSP Scope/Severity, which has several values to select from: High (1), Medium (2), Low (3), Very Low (4), or N/A. These values represent the estimated impact of the defect on the command’s business or processes in Navy ERP. The command considers high-impact defects to be a higher priority for resolution than defects with a rating of Medium or Low. The impact rating is used as input for the CRRB prioritization process.

The weekly process for ensuring new QCIs are evaluated and QC is updated is depicted in Figure 4-2; follow on steps provide detailed description of the process.

+ SCOPE Guidelines

1 Affects 90% of Fleet Customers/power users at a Command; OR a very large range of system functionality (2 or more critical business processes);

OR impacts multiple Commands totaling more than 90% of Fleet Customers/power users

2 Affects greater than 10% and less than 90% of Fleet Customers/power users at a Command AND/OR a large range of system functionality (an entire critical business process)

3 Affects greater than 1% and less than 10% of Fleet Customers/power users AND/OR a moderate range of system functionality (non-critical business process)

4 Affects greater than 5 Fleet Customers/power users and less than 1% of Fleet Customers/power users at a Command AND/OR a small range of system functionality (pieces of a business process)

5 Affects a minimal set of Fleet Customers/power users (<5) AND/OR a very small range of system functionality (one piece of a business process)

+ SEVERITY Guidelines

1 Mission Critical Functionality* is unavailable with NO workaround OR at least 1 of the following: Potential for Loss of Life, Data loss/Data corruption; System unavailable; $5M+ impact for Commands with > 5,000 Fleet Customers/power users; $1M+ impact for Commands with < 5,000 Fleet Customers/power users

2 Mission Critical Functionality* is available WITH workaround OR $1M-$5M is impacted for Commands with > 5,000 power users;

$.5-$1M+ is impacted for Commands with < 5,000 power users

3 Non-Mission Critical Functionality is unavailable with NO workaround OR <$1M for large Commands; <$.5M for smaller

4 Non-Mission Critical Functionality is unavailable but has viable workaround

5 Cosmetic issues or some functionality is unavailable but has a simple workaround

Scope UPS Priority

1 3 2 2 1 1

2 3 3 2 2 1

3 3 3 3 2 1

4 3 3 3 3 2

5 4 3 3 3 2

Severity 5 4 3 2 1

+ Command Impact value of N/A applies where QCI is not relevant *Mission Critical Functionality – Adverse impact to direct support of fleet operations/missions OR command essential functions (e.g., period end close, pay vendors, pay people, send/receive funding, billing, ADA violations…) OR to audit readiness.

Navy ERP Universal Prioritization Schema

SPEBO Release Management Plan_20171204 Final.docx Page 21 of 24

Figure 4-2: SPEBO Incident Management Process

Step 1. Weekly Data pull from QC: Every Sunday/Monday morning, Release Management Team pulls raw data from QC that includes all items identified as not rejected, not deferred, and not closed.

Step 2. Analyze and Develop Delta File: Every Monday, the Release Management Team compares the SSP QC Master List, which contains all QC items that have been reviewed by SPEBO Team Leads and their input, to the weekly QC raw data file. The weekly QC raw data file is filtered for those QC items that have not previously been reviewed by SPEBO Team Leads and is then compared to the SSP QC Master List. After this analysis, should there be any QC items on the weekly QC raw data list that are not on the SSP Master List, the delta items are put on a separate spreadsheet and provided to the SPEBO Release Manager for review and distribution to the SPEBO Team Leads. If no deltas are discovered, there is no additional action required for that specific week.

Step 3. Release Manager/Update Weekly QC Delta file and Distribute: The RM reviews the QC delta file and, if required, updates the SPEBO Team column and then distributes to each SPEBO Team Lead for their input.

Step 4a-d. SPEBO Team Leads review Weekly SSP Delta File and Provide Input: Once a QC delta file is received the SPEBO Team Leads are required to review all QC items where they are identified as the Lead. For those QC items, the SPEBO Team Lead inputs the information below into the QC Delta List received and forwards back to the RM and Release Management Team. Input required includes:

Pull raw data from

QC

No

SP

EB

O R el ag er

Re le as e

M an ag em en t

Te am

SP

EB

O

T m

Le ad s

SSP Incident Management Process

Delta(s) discovered?

Create spreadsheet with delta(s) and send to SPEBO Release Manager

Yes

Analyze raw data and compare against QC Master List

Review and update “SPEBO Team” column on spreadsheet before distributing to SPEBO

Team Leads

Review QC Items inputting required information on spreadsheet

4/3/2017

Review and input feedback into QC

Consolidate responses and update SSP QC

Master List

Post QC Master List to SSP

Livelink

Step 1

Step 3

Step 4

Step 5a

Step 5b Step 2

No new delta file created/sent for the week

SPEBO Release Management Plan_20171204 Final.docx Page 22 of 24

a. SSP Scope/Severity (1-4) - The SPEBO addresses the impact of QC items on the command by assigning impact ratings. The impact rating assists Navy ERP with prioritizing open defects for resolution each month. Impact priorities are described as follows:

i. 1 - High Impact: Serious, Could cause major cost and/or schedule increases. Secondary requirements may be impacted. Workaround causes redirection of significant work years/efforts and workload impact to duties. Significant number of users or functions impacted.

ii. 2 - Medium Impact: Moderate. Would cause noticeable cost and schedule increases, however important requirements would still be met.

Workaround exists, medium workload impact to duties.

iii. 3 - Low Impact: Minor. Requirements would still be achieved, workaround exists. Low workload impact to duties.

iv. 4 – N/A: The item is not applicable to SSP business processes.

b. Testing Type - This field indicates whether the SPEBO Team Lead is expecting to participate in the testing of the QC items prior to being released to production.

The testing can range from participant(s) actually performing testing, which requires the participant to provide a test plan to Navy ERP PO at least 3 weeks prior to the scheduled release, or SSP Team Leads can participate as an observer (either on-site or via DCO) or can determine that testing is not required.

c. Testers - If Team Lead determines that testing is required, they need to provide the name(s) of the testing participants. This allows the Navy ERP PO to contact participant(s) regarding date/time when testing will be conducted.

d. SSP Priority (1-10) - The most important aspect to Sustainment Management is ensuring the most significant items related to SSP business are being managed.

All commands rank their top 10 items, and it is possible and acceptable for more than one command to rank the same item, at a similar or different ranking. The Navy ERP PO works the Command Priority one items first then the remaining items quickly as they can, however, technical dependencies and resources may not allow for items to be worked in order. This field provides the Team Lead the capability to identify those QC items that they believe to have the highest priority for the SSP Command. As required, the RM reviews with the Director and the Team Leads all SSP priorities and reprioritize from highest to lowest.

Steps 5a-b. Deputy Director and Release Management Team personnel review and input information into QC:

a. Release Manager: Once the weekly QC delta files are received, the RM reviews responses from Team Leads and then inputs the information into QC.

b. Release Management Team: Once the delta files are received, the Release Management Team consolidates all responses and then updates the SSP QC Master Data List. The QC Master Data List is then posted weekly to SSP Livelink at:

https://sphqdm1.sphq.ssp.navy.mil/Livelink/livelink.exe?func=ll&objId=3203701

SPEBO Release Management Plan_20171204 Final.docx Page 23 of 24

5.0 Communications

The Navy ERP PO disseminates detailed release notes prior to each scheduled release to summarize changes to each release item. The Navy ERP PO disseminates an email of unscheduled release items but does not issue detailed release notes.

5.1 Release Notes

For scheduled releases, detailed release notes are disseminated from Navy ERP approximately two weeks prior to the…